Thanks for the response, Alex. That's certainly possible in some cases. But it seems like there are at least a few situations where you wouldn't want to or are unable to put these methods into the model:
For example, maybe this model is not under your control. Perhaps it's in a different app, or perhaps it's part of the base Django distribution (as is the case with the User class, for example). If you can't add methods to classes such as User, where do you stick them? Or another case is business logic that doesn't map directly to an existing model in your app. Methods related to interfacing with external services such as Facebook or Pownce might fall in this domain. Your app might not have a Facebook model, so where do you put business logic related to Facebook? Even if you can find a place in one of your models to put logic like this, I'd argue that there are times when it doesn't truly belong in the model. The example I brought up before was putting a "send_email" function into your Invitation model. Sure, you can do this, but it introduces a lot of dependencies into your model that don't really belong there. Should your model know how to send emails? How to render email views? Which email template to use? Sure, as you suggest, you can pass the template to use as a parameter, but what about if you want to send invites as IM or SMS, or just display the url for the user to copy-paste to their friends? You end up with a proliferation of send_XXX methods that I'd argue are probably best to keep out of the model. So I guess I'm just curious to hear how other members of the community have solved this. Are people slipping business logic into the model classes for the most part? Cheers, Mike On May 1, 3:16 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > You actually would place the on the model, for example you might have > a send_email method on an invitation model, to abstract the template, > simply make it a parameter to the function. > > On May 1, 5:07 pm, Michael Burton <[EMAIL PROTECTED]> wrote: > > > I'm coming to Django from the Java Spring MVC world, and over in those > > remote lands we have something called a "Service" layer. > > > The service layer is responsible for doing all the business logic that > > your views might otherwise do. For example, you might have something > > like: > > > class UserService: > > def create_user(self,...) > > def create_friendship(self,user_a, user_b) > > > or maybe: > > > class InvitationService: > > def send_email_invitation(self,...) > > def redeem_invitation(self,invitation) > > > These services would be instantiated as singletons which would then be > > used by higher-up layers like the views. They would typically be re- > > used between different views (eg. iPhone, desktop, and REST views > > might all use the same service). > > > Looking at Django, I don't see an obvious place to put these sorts of > > common business-logic methods. They don't really belong in the views > > since you don't want to have to reimplement them every time you add a > > new platform. But they also don't belong in the models, since you > > might not want to tie your models to presentation-specifics such as > > which email template to use.[1] > > > I'd like to do things the "Django way", so I thought I'd put the > > question out to the community. Where would be the best places to put > > business logic like this? > > > Cheers, > > Mike > > > [1] In addition, there might not be an obvious model for a particular > > kind of service. For example, what model would you use for a > > FacebookService, if you need to integrate with the facebook platform? --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
