These are chat archives for django/django

15th
Feb 2018
Ghost
@ghost~5a83b5e1d73408ce4f8d0deb
Feb 15 2018 03:12
thanks @emihir0
Renato César
@rencesar
Feb 15 2018 09:08
I have a question, if we divide the layers in django then we will get Presentation Layer (Views, Templates), DataBase layer (Models). It's a good practice create a Business Layer Based in the Django models with getters, setters, extra fields and calculations?
Roel
@roelzkie15
Feb 15 2018 09:12
@rencesar Yes, you have to think a thinner View and Thick model or form. You can write most of your business logic inside form or model rather inside view. It is a good practice.
Renato César
@rencesar
Feb 15 2018 09:19
But on the company that I work We create a new object for each model that and we do all the calculations and all the logic stuff in this object, and we present this object instead of Models Object. Even the Serializers of Django Rest framework We do in this object. But I'm no sure if it's a good practice or Django recommendation.
What do you guys think about it?
Roel
@roelzkie15
Feb 15 2018 09:22
@rencesar i think it is quite alright sounds like you are trying to make a decoupled object that do dynamic calculation and render that data from the client. That as well is a good practice.
Renato César
@rencesar
Feb 15 2018 09:26
That's good because I think that it is super productive hahaha
Roel
@roelzkie15
Feb 15 2018 09:36
@rencesar yeah, as long as you limit your code inside the views, just do separate layer (model, forms or any object that will represent the data to view) for bulky business logic
Pete Tinkler
@ptink
Feb 15 2018 16:27
has anyone hit upon a nice pattern for handling multiple clients/environments with docker? I'd love to avoid having to type docker-compose -f docker-compose.yml -f docker-compose.client1.yml -f docker-compose.prod.yml up -d I was going to do it with environment variables and run env THING=BLAH docker-compose up -d but that's non-trivial on Windows and we use Windows and *nix here
also looked at using the extends keyword but that apparently got blatted in v3 and doesn't look like it's going back in any time soon
i feel like this has got to be a common problem, surprisingly difficult to find a solution though
emihir0
@emihir0
Feb 15 2018 20:47
@rencesar if I understand it right, you are just making a very thin layer on top of your model to do your business logic, which is OK ofc, but from what you've described it seems kind of redundant - why not just put that logic directly in models/managers?
there are quite a few great built in tools into models and managers that make you very productive (e.g. validators on fields etc)
Renato César
@rencesar
Feb 15 2018 20:52
Well, we think that models are in the data base level and we want separate the database layer from the business layer. To do that we create a Separate kind of models that we can put extra fields and also calculations, and the idea is never put models in the views, only the business objects.
Muhammad
@mraza007
Feb 15 2018 23:40
Hi guys I need help
I am trying to do search function view in Django
I don’t know how to get started should I share my code
Roel
@roelzkie15
Feb 15 2018 23:49
@rencesar It is a good idea, but do not ignore the extent of model function/property setter, getter there is a lot of benefits in django way. nice idea though, i encourage you to share your architecture.
@mraza007 post your code
emihir0
@emihir0
Feb 15 2018 23:54
@rencesar models are not at database layer, ORM is an abstraction above database layer... I'm not saying that what you are doing is wrong, I just think it might be abit pointless. Let me give you an example - a built in User model has 'email_user' method which is clearly a business logic method. Having models for the sake of just storing fields in them means you don't use so many useful features built into the models/managers/querysets...
@mraza007 search function for what? e.g. search your User model by first_name and such? well, you need a form for that. The form will send a request to your view (which can be a function) with either get or post data and then you just use that data to filter your queryset
I suggest looking at django-filter library: https://django-filter.readthedocs.io/en/1.1.0/ it is very useful