Re: keep models simple ? where to put the business logic ?

On Apr 22, 7:51 pm, Michael Palumbo <michael.palumb...@gmail.com>
wrote:
> Hi,
>
> I know this has already been discussed several times, I found several posts
> about it through Google but I'm still interested in getting your opinion on
> an example.
>
> I'm wondering that because my models file is getting big. That makes me
> confused so I'm wondering if I'm doing the right thing from a design point
> of view.
> I have the feeling that my models should remain simple. What do you think ?

https://www.google.com/search?q=anemic+domain+model

> For example, let's say I want to create a model named Feed. (simplified
> version)
> class Feed(models.Model):
>     name = models.CharField(max_length=255, unique=True)
>     url = models.URLField(unique=True)
>     etag = models.CharField(max_length=255, null=True, blank=True)
>
> I want to be able to extract a feed (that is to say to download it and
> store it(as a file but I also keep a track in the DB through a File
> model)). Would you create:
> - an extract method in the model

That's probably what I would do.

>
> - a view:

Nope. The view should just deal with user interactions (in this case,
allow a user to launch the extraction).

FWIW, a part of the Django code I see suffer from this problem (anemic
domain, and anemic forms to), and it's a major PITA when you want to
extend such a code, because you have business logic and user
interaction logic deeply mixed in the views for no good reason.

> - a "util" function to whom I pass the Feed object.
> f = Feed.objects.get(pk=1)
> utils.extract_feed(f)

How is this better than having the very same function being a method
of the model ?

Models - like any other module - should indeed be "as simple as
possible", _but not simpler_. If you concern is about your models.py
file size, it might be time to refactor it into a package.

Now if there are parts of your methods that are low-level enough and
don't really need to know about your models, yeps, they may belong to
some "model-agnostic" utility module. Refactoring methods this way can
help keeping the method code hi-level and readable.

My 2 cents

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.