On Jan 31, 4:09 am, Haron Media <[email protected]> wrote:
> I wonder how you build your models, do they handle all the data logic?

Generally, but I think there may be also a case for "services" that
use multiple models.


> Porting myself to Python/Pylons, I have to learn to use SQLAlchemy
> properly because looking through the 300+ pages of its documentation it
> seems complex but very powerful, especially its ORM.
>
> However in my PHP apps I always contain all the data logic to the model
> itself. The controllers only call specific methods in order to do
> something with the model, not the data directly:

This is the approach I use. My thinking is that the model should be
separate from any user interface or application. I view a Pylons app
as a (thin) layer that adapts a model (and perhaps services) to the
Web (as a UI or Web services). As such, I usually implement the model
in a separate Python package.


> loadById() would load model data into its properties from relevant tables.

Nitpicky style point: the prevalent style for function/method names in
Python is load_by_id. See PEP 8.


> save() would check
> if pkey is set, and then insert or update existing rows accordingly.
>
> Also, since I work exclusively with transactional Postgres, I like to
> rely on constraints to tell me  what's wrong. Instead of locking entire
> table to see if new data would produce duplicates in columns that should
> be unique, I rely on the DB transaction to raise Constraint Violation
> error from which I read the column in question and can inform the user
> to modify this or that field in the form, because it's duplicate.
>
> The problem with that is that the DB engine throws a generic Constraint
> Violation from which I have to "extract" constraint name, and produce a
> meaningful message to the user, like "Name already exists, please try
> another". Therefore I catch generic SQL exceptions in the model save()
> method, and re-throw custom exceptions made for the model like, for
> example, NameDuplicateError, or EmailDuplicateError, etc... so the
> controller can catch these and send back proper message, or alter the
> form to highlight fields in question.
>
> I wonder what other patterns would you guys use?
>
> Vlad

-- 
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.

Reply via email to