On Wed, Jul 02, 2008 at 09:45:58PM -0700, Mike Orr wrote:
> So when I needed a a semi-generic auth library that uses three tables,
> I put the integrity-checking function in the model because it depends
> on several custom queries. But the main auth code, which checks the
> password and instantiates the User object containing the permissions,
> is in a lib module.
Just for an alternate perspective...
I've taken a rich-model approach. Since the model defines the objects
that the application uses, it's very natural to make the objects rich
by extending their business-logic functionality in the model.
In my version of the above, I'd have a User object that was capable of
doing something like:
try:
u = model.User(username, password)
except AuthFailure:
...
Higher-level business logic that combines many different pieces of
functionality from different model objects goes into the lib.
I've found one downside to putting more functionality inside the model
code. Suppose there are two classes, model.A and model.B. If A
refers to some piece of B, it's very easy to run into circular import
statements. Fixing that is a bit of a headache, but I've gotten
better at not doing that :)
--
Ross Vandegrift
[EMAIL PROTECTED]
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
