Django Business Logic – Where to Place Python Business Logic in Django

business-logicdjangopythontemplatesview

I have just begun to learn Django/Python/Web Development. This problem has been troubling me for a while now.

I am creating an application with multiple templates in Django. I have a views.py which is basically just rendering the responses to the respective templates and I have a models.py where I have structured my DB. In one of my templates, I need to upload an image (which I am able to do) and I need to run a logic which is based on the features of the uploaded image (not yet done). This logic involves a lot of heavy calculations. After performing the calculations, the logic should return some processed information (coordinates) to the template.

I have been able to do all this actions successfully in a standalone python desktop application calling python files one after the other. However, since I now want to make this a web application I have begun using the Django framework.

I have done a lot of searching but I am still not able to figure out where exactly should I place this Python file containing all the logic. Should I have another class based file (logic.py) and call it from the view.py? I googled and found that many developers are placing their business logic in their models.py in Django. However, I feel it is intuitively not right since model should exclusively communicate with the back end. Any help would be appreciated.Thanks in advance.

Best Answer

I have done a lot of searching but I am still not able to figure out where exactly should I place this Python file containing all the logic.

There are a number of options, depending on what your requirements are:

  1. Add the logic to e.g. the Image model. This is a useful option if you need to store per-image meta data in the database, and each model instance (each image) is processed by itself.

  2. Add the logic as a plain Python Image class, e.g. in a file called image.py. Nothing in Django restricts you from adding logic other than that in the views or models modules. This is a good option if the image logic is a central component of your Django app (e.g. a Image processing app).

  3. Create a separate Python project that provides the logic, then call it from your views. Make sure to install this project in your Django app's Python environment. This option is valid if the purpose of your Django app is to upload and view images, or to show the results of the image processing in direct response to a user's request, but where the image processing could be used by other projects too.

  4. Create a separate app that processes requests asynchronously and is run separately from your Django app. This option is useful if you need to decouple the image processing from the request cycle of the app, process large number of images, or where each calculation takes too much time to solve within a request cycle's time (say within at most 500ms to 1s).

I feel it is intuitively not right since model should exclusively communicate with the back end.

There is nothing in Django that requires a model to communicate with the back end, or rather the database. I think you are mixing the semantics of what Django typically considers a model (namely, an abstraction of one or several tables in the database), v.s. the term model as a design construct (e.g. as in Domain Driven Design).

Related Topic