On 17/12/10 14:37, Paul Poulain wrote:
Le 17/12/2010 15:30, Colin Campbell a écrit :
Most of those routines are far too large and unmaintainable, many read the same data repeatedly and all mix business logic and reading data. It would probably be good if the "things" they deal with were abstracted into proper objects that police their own destruction, it would also give you the chance to have a more guaranteed interface to e.g. Item so that we dont have to scatter validations about through the business logic. Its one of the attractions of an ORM that it does this for you but you don't need an ORM to do it. I think if you can abstract away some of the current complexity it gets easier keep things clean. Hi Colin : so... who's first : the egg or the chicken ? (frenchism suspected)
Because an ORM can't be achieved without persistency (or we will get awful response times...)
I'm in favor of doing one step after the other, and ORM is the step #2, after persistancy that is the #1. IMO, if you disagree, pls argue & convince me.
Many people implement persistency by using an ORM but if you look at what I wrote I said we did not need an ORM to achieve this. C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com