chris mollis wrote:
> Agreed.. data persistence should never be tied to the domain model.  
> That's precisely the problem with ActiveRecord (sic Django/RoR)
whoa,  first Django and RoR do work for thousands of people / sites.   
The question is can something else work even better?  The goal is what 
is productive for users and still produces a responsive  data model.   

As I mentioned, I actually prefer the DataMapper approach where your 
data definition is in the file along with your ORM functions - the 2 
have to be in synch and this is the clearest way to do that.   I also 
really like the way DataMapper automagically handles migrations - you 
change the definition and simply run an update.   That is really 
productive in an agile way.  What I don't like about Django ORM is that 
it automagically changes table names (puts the project name on the 
front) and create foreign key fields without any "_id" which is much 
clearer in terms of what you have in your data.   In other words a good 
ORM should work with existing SQL data tables and leave the tables in a 
clear way. 

I guess there is still the discussion of what is better: a specific 
mapping vs "has_many" - the "has_many" is easier, more productive, the 
mapping is clearer, less magic.  Maybe someone has a way to do both? 



> style of db development.  It's treated as an afterthought when in 
> fact, the database is the most common point of contention within any 
> web application and usually requires the most optimization (from 'back 
> to front'.. not 'front to back').
>
> Moreover, deviating from this approach presents incredible problems 
> with development, requiring forks from the prescribed pattern..  
>
>
> On Wed, Jan 21, 2009 at 4:20 AM, Paweł Stradomski 
> <[email protected] <mailto:[email protected]>> wrote:
>
>
>     W liście Jan Koprowski z dnia środa 21 stycznia 2009:
>     > In MVC *M*odel should be abstract layer of data and hide data
>     > representation and real method access giving: universal, good
>     > described, readable and simple interface to manage this data: add,
>     > remove, get all, get one etc... methods.
>     >
>     One could say that Active Record (django style) is a more leaky
>     abstraction,
>     as it ties persistence to the domain model. Read more on orm
>     patterns (Active
>     Record, Table/Row Gateway and Data Mapper in Fowler books).
>
>     Model layer should not be (IMHO) monolithic - data persistence
>     should not be
>     tightly coupled to your domain model, while Active Record does
>     exactly that.
>
>     So your model should have a low-level layer that does the
>     persistence, and
>     high-level domain logic layer that deals with your application logic.
>
>     Also, your controllers should probably not use session object at
>     all - you
>     could wrap all the high-level processes (eg. user creation, posting an
>     article etc.) in functions (maybe classmethods) or classes in the
>     model
>     layer.
>
>     Just out of curiosity... which University of Technology? The
>     Kraków one (AGH)?
>
>     --
>     Paweł Stradomski
>
>
>
>
> >


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