>> >> As well as not querying relations that are not required, it's also key >> to minimise the query count to get the data (attributes and collections) >> that is required, and execute the most efficient queries possible >> according to the underlying database's capabilities and quirks. > > A small note: less queries != more efficient. More efficient is more > efficient, and sometimes that means returning one table and then > querying directly a related table. Query count should be /constant/ > once efficiency tradeoffs are established : but less is not always > more. >
Agreed, and this is what I was trying to say but clearly my wording was unclear :-) >> >> I think the pseudo code which I have snipped out reflects it, but in my >> view we also need to ensure where is a clear separation between the >> verbs/actions and the nouns/model. eg so the bugs collection class >> (whatever it is called - IBugCollection, IBugs, IBugManager) should have >> methods like findUnassignedBugs() or findBugAssignedTo(IPerson) rather >> than the apis just mentioned being on the IBug interface. > > mmm, I'm not convinced either way here. I think we have room to play > it a couple of ways. > I prefer it that way I mentioned because it helps keep separate concerns in the right places. Business services should be the abstraction used to define verbs - queries, business operations and the like - these are then often exposed via other mechanisms such as a web service layer etc - the higher up the stack, the increasing amount of consolidation. The thing being modelled - the nouns - should reflect the state of the object model and relationships between the objects but not the operations performed on them. IMHO :-) >> >> One extra point I would like to make in relation to the LEP: >> >> "Not requiring a cache in the layer" >> >> In my view, we need to distinguish the type of cache we are talking >> about. If we are talking about a L2 type cache with an object >> lifecycle/ttl which spans individual system interactions with the >> persistence layer and which implies the need for replication in a >> clustered environment to maintain data consistency, then I agree that we >> should try and avoid the need for this. However, I think some form of >> caching within the bounds of a single interaction is useful and perhaps >> necessary to minimise unnecessary hits on the database. The cache is >> discarded when the interaction ends but allows objects already loaded >> (whether via a single getById type operation or as a result of a query) >> to be accessed from the cache if required. This is all done >> transparently by the implementation so no explicit user code is required >> to make it work. Hibernate uses this concept with its Session construct. > > The hibernate Session lives at the ORM layer; this is above that layer > I think : there may well be an ORM layer, but lets not conflate > responsibilities. > I was just using it as an example to illustrate the concept I was trying to get across :-) Perhaps not the best choice. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
