From the Django docs
Adding extra Manager methods is the
preferred way to add “table-level”
functionality to your models.
- Create a module with that logic (
Lets say you have a model
Employee, so, you should create class for managing employees:
class EmployeeManager(models.Manager) def of_the_year(self): from year_employee import my_calc_func return my_calc_func()
Then add this manager to your model
objects = EmployeeManager()
After that you could simply do this:
chosen_employee = Employee.objects.of_the_year()
As for django, the best place to put business logic is inside models. The view should be clean from business logic and should only be used to get the data to be displayed/presented on template or in other words let the view be used for view logic only.
From django FAQ:
In our interpretation of MVC, the
“view” describes the data that gets
presented to the user. It’s not
necessarily how the data looks, but
which data is presented. The view
describes which data you see, not how
you see it. It’s a subtle distinction.
By putting your business logic under models, it will lead you to unit test easier because models is not coupled with HTTP methods or processing.
- putting logic in View will not allow
you to write unit tests easily and
can’t reuse effectively.This says
that you should never put the
complex logic in a view you should
separate it from the view.
- If logic is closely tied to a
(class/objects of a class) putting
that logic in the model makes sense.
- In case the logic is closely tied
multiple objects/classes you can use
one of the model to put logic or you
can create a service object (or when the code is too huge) which
will handle this logic.
- Is there any list of blog engines, written in Django?
- How to set settings.LOGIN_URL to a view function name in Django 1.5+
- How to assert django uses particular template in pytest
I concur with those who think that such logic should be placed within the models.py files. However, something as big as what you have, with over 1k lines of code, would start to clutter the models.py files [for me]. I would be inclined to move such code in a separate file within a given application. No harm in doing that.
- Django QuerySet Custom Ordering by ID
- Uwsgi http is ambiguous
- Django CSRF when backend and frontend are separated
- How to write a Django view for a POST request
Is this a custom application? If yes extracting the business logic away from the view is not really going to be at all possible. Sometimes you have to put it in there for a myriad of reasons, one of which would be maintainability.
Beyond that a calculation should be outside of the UI, in 99.9 % of the cases.
I try to follow the “skinny controller, fat model” concept (link is specific to Rails, but the concept still applies). Your controller should not have much code in it at all, except to deal with sessions, cookies, forms, etc. All of the actual logic of your app should reside in your model, making it easier to test and refactor later.
- Access token from view
- Using existing field values in django update query
- Django-registration, template
With regards to your specific example “a method to calculate best employee of the year (1000 lines of code with a complex logic) … where should I define it and who will call it?”
For that much code, I would probably make a new module (perhaps ranking.py) and put it there. Who will call it depends on how you use it, but I would guess that it would be called from one of your views.
- How to point correctly to static image in django
- Django's get_current_language always returns "en"
- Force delete of any previous test database (autoclobber) when running Django unit tests, eg, in PyCharm
From your inputs:
Defining a separate module “services.py” for holding methods / classes with complicated algorithm and logic.
As we know eventually the call will be made from views (who knows what it wants) so the best we can do is to call a method in models which internally calls the logic from services module, uses models data to do the processing and return the result to be written on to the response.
Thanks for your responses.
- Django Admin – add collapse to a fieldset, but have it start expanded
- Django cascade delete on reverse foreign keys