This was a really interesting thread, and I'm glad I started it. The persistence layer project I'm kicking off - https://dev.launchpad.net/LEP/PersistenceLayer - may not go as far as I proposed at the start of this thread.
Still, I want to address some of the concerns expressed in the thread though, specifically about redundant class definitions. I think we will end up with redundancy in our definitions, but it won't be valueless. On a related note I'd like to nuke the interfaces that don't carry their own weight, and will certainly not be adding noddy interfaces in the persistence layer itself. The reason I think we'll end up with some redundancy is because by having a separated layer, we either have extremely structureless things - e.g. a single subclass of object with implementsInterface() called on it and attributes set, or roughly one class per conceptual thing we bring back from the tables. I think the latter is better because it does permit writing object centric code when we think that that makes sense. Having the option is nice. As a for instance, I'd expect something like: class Entity: class Person(Entity): class Team(Entity): in the business layer class Person(SQLBase): ... and class PersonMapper(Mapper): in the db layer. (And for testing a TestPersonMapper, which is in-memory). The most important things though, of all of this, are twofold: - we should be able to tell when code is business or storage. - we should assume single-object manipulating query/update code is faulty. *thats* something we can assume now, but it will take a lot of effort to change things, so I'm not going to vigorously push on this meme until we've got the persistence layer well underway. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
