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

Michael, I'm split on this – I think it really depends on the situation. If these access methods are like low level api to be used in higher end code I would then throw a custom error and use debug level log only, then in your view I would catch an error when NoDataReturned and log it as warning.

 

Perhaps the question to ask is: what data set I want this method to return.  Either homogenous: always a 'data' of certain type (with a possibility of an Exception), or heterogeneous that is either the 'data' OR None, if it's the latter you are using if/elif blocks if it's the former you are using try/except.  A homogenous data set is cleaner and easier to debug in my opinion for such a highly dynamic language as Python. (for opposite see Haskell).

 

From: Michael Palumbo

Sent: Friday, April 27, 2012 6:17 AM

To: django-users@googlegroups.com

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

 

Any suggestions about catching and logging errors right in the models functions ?

Le mardi 24 avril 2012 13:32:27 UTC+2, Michael Palumbo a écrit :

Hi guys,

Thanks for your answers, it helps.

- Anemic domain model : I didn't know about this before, it is good to know.
- Daniel : if I split my models and import all of them in my __ini__.py file, why do I still need to use the app_label meta ?
I know I have to because when I run the syncdb command, it does not work unless I specify the app_label meta but I'm really wondering why since I can still access to them normally like it would be with one file: "from my_app.models import model1".

So now I'm convinced that business logic should remain in the models, my doubts are gone now.
However, my feeling of having a complex models might also come from the fact that I put some numerous try..except blocks inside my function and log the errors.
So my question is: when raising and catching errors and when logging ?
We could say that catching errors and logging are not part of the business logic either and they should thus be on a higher level ?

Should I catch the errors inside my extract function and log them.
Or should I wrap the call of feed.extract() with a try..except block and log them ?
Maybe it depends on the nature of the errors ?

For example, the download_from_url method will success only if there is data to return. For example, if the etag is different, it raises a DataNotModified exception, etc.

For now, I catch it, log it, and return None on my extract method.
def extract(self):
       try
              data, etag = utils.download_from_url(self.url, self.etag) #Download from the url
              f = self._store(data) #Store it
       except (DataNotModified as e):
              logger.warning(e)
              return none
       except (X as e):
              logger.error(e)
              return none
       except (Y as e):
              logger.info(e)
              return none
        

       self.etag = etag # Change the etag 

       self.save()

       return f


What do you think ?

Thanks
Best,

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/xIv_DaMs02gJ.
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.

 

Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.com/