http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Ayende "Can you give me the use case that would require this branching of logic? " I have a blog post which discusses these issues in the context of lazy loading. http://www.matshelander.com/wordpress/?p=45 I try to describe examples of branching logic in it. My conclusion is that it is not really feasible to try to load everything up front if you also want to build well factored and reusable code. /Mats http://ayende.com/2584/query-building-in-the-domain-service-layers#comment13http://ayende.com/2584/query-building-in-the-domain-service-layers#comment13Fri, 22 Jun 2007 09:16:09 GMTCan you give me the use case that would require this branching of logic? http://ayende.com/2584/query-building-in-the-domain-service-layers#comment12http://ayende.com/2584/query-building-in-the-domain-service-layers#comment12Fri, 22 Jun 2007 09:02:37 GMTWhoops: C/P error ;-) Unit of work registers “updates”, to be simultaneously updated. Query Unit of Work registers “reads”, to be simultaneously updated. Should read: Unit of work registers “updates”, to be simultaneously executed. Query Unit of Work registers “reads”, to be simultaneously executed. http://ayende.com/2584/query-building-in-the-domain-service-layers#comment11http://ayende.com/2584/query-building-in-the-domain-service-layers#comment11Fri, 22 Jun 2007 08:49:49 GMTThe registration phase is like a Unit of Work for queries. Unit of work registers “updates”, to be simultaneously updated. Query Unit of Work registers “reads”, to be simultaneously updated. Only the problem how do you avoid loading to much, when with a lot of logical branching in the behaviour. Perhaps there is a need to map Simple OO behaviour to Query language?. Does that sound a lot like LINQ? So OO behaviour can state a logical branch for queries, like : Register in Query Unit of Work -> “Get Special prices goods if customer is gold else Get Homepage data”, and the Query Unit of Work would automagically do the check for “customer is gold”, in the query. This would be fairly easy with simple data (fieldvalue or sum etc.), but more complex (nested) scenarios would be hard to make? Also this would probably hurt scalability, since we now do our conditional logic in the database? http://ayende.com/2584/query-building-in-the-domain-service-layers#comment10http://ayende.com/2584/query-building-in-the-domain-service-layers#comment10Fri, 22 Jun 2007 08:48:03 GMTDo you really want to run queries that may be potentially on behalf of unauthorized users? It's not like you can describe any data or policy dependencies among the queries you put in the MultiCriteria so there's a limit to how far this can be taken. Really I'd like to see this kind of thing happen with a proper data-flow oriented language where data dependencies can be clearly traced and opportunities for data parallelism exploited to the fullest extent without a whole lot of hand tuning. @Aaron Jensen, the registration phase you're describing reminds me of Futures. http://ayende.com/2584/query-building-in-the-domain-service-layers#comment9http://ayende.com/2584/query-building-in-the-domain-service-layers#comment9Fri, 22 Jun 2007 08:20:30 GMTThe registration stuff is the first thing that came to my mind after reading the post too. The registration phase would be as easy as just writing the queries you want... they'd all return proxies. The proxies would be smart enough to know what their original query was so that things like Where.Policy.Customer.In(customers) would build a query w/ a subselect. In other words your first example code would work just fine and only do a single query the first time one of the entities was accessed (customers[0] would exec that multiquery) Just imagine if it was combined w/ Adaptive Fetching Strategies (http://blog.eleutian.com/2007/06/01/AdaptiveFetchingStrategiesInORMs.aspx) Every query in every controller would have a strategy... oh what a beautiful world that would be. http://ayende.com/2584/query-building-in-the-domain-service-layers#comment8http://ayende.com/2584/query-building-in-the-domain-service-layers#comment8Thu, 21 Jun 2007 18:43:49 GMTWhat I am doing right now is a base class method that gathers all the queries, and then get them back afterward. The registry is a bit too complex for my needs right now. But yes, the queries can get fairly massive ;-) http://ayende.com/2584/query-building-in-the-domain-service-layers#comment7http://ayende.com/2584/query-building-in-the-domain-service-layers#comment7Thu, 21 Jun 2007 14:32:36 GMTI'm envisioning a per request query registry of some sort where objects can register the query they need run with a callback. The registry will make a single mass, multi-criteria call to the server, then notify each registrant that their results are available....oh the possibilities. http://ayende.com/2584/query-building-in-the-domain-service-layers#comment6http://ayende.com/2584/query-building-in-the-domain-service-layers#comment6Thu, 21 Jun 2007 14:10:17 GMTDetachedCriteria.For<Policy> is actually a way to specify a query without the need to have the session available. http://ayende.com/2584/query-building-in-the-domain-service-layers#comment5http://ayende.com/2584/query-building-in-the-domain-service-layers#comment5Thu, 21 Jun 2007 09:55:54 GMTNice code!!! In my view it`s very interesting and I would be more deeply investigate it, but some pieces of code isn't understandable for me... :-( for example what is the best practicies for using this construction? DetatchedCriteria<Policy> It`s kind of some repository or I make a mistake ?! http://ayende.com/2584/query-building-in-the-domain-service-layers#comment4http://ayende.com/2584/query-building-in-the-domain-service-layers#comment4Thu, 21 Jun 2007 09:01:06 GMTTobin, The second way execute it in a single round trip. Yes, the second query is less explicit initially, but you learn to grok that fairly quickly. The syntax that you suggest is interesting, and certainly possible. http://ayende.com/2584/query-building-in-the-domain-service-layers#comment3http://ayende.com/2584/query-building-in-the-domain-service-layers#comment3Thu, 21 Jun 2007 07:57:41 GMTIf I understand this correctly, will that code result in *one* trip to the server where 2 queries are executed like this? 1. "select * from customers where blah = something" 2. "select * from policies where customer_id in ( select id from customers where blah = something)" I personally like the idea where a query in multicriteria can be made to use the results of a cloned query, it's neat. I've not used detatched queries but I can't wait to, I often see query construction and execution as separate concerns so they fit nicely. The fact this is all happening in one round trip is great too. The 1st code sample is short, simple and easily understood. The 2nd option is much less explicit though. It took me about 4 reads to get a feel for the code, possibly because there are many more additional concepts involved: - Deatched Queries - Multi Criteria Queries - Projection - Object Cloning I don't use these in my applications yet, which could be why they're a little overwhelming for me. This might be clearer though if it were possible? DetatchedCriteria<Customer> customersQuery = AuthorizationService.GetAssociatedCustomersQuery(); DetatchedCriteria<Policy> policiesQuery = Repository<Policy>.DetatchedFindAll( Where.Policy.Customer.In(customersQuery) ); results = session.CreateMultiCriteria( customersQuery, policiesQuery ).List() ICollection<Customer> customers = results[customersQuery]; ICollection<Policy> policies = results[policiesQuery]; http://ayende.com/2584/query-building-in-the-domain-service-layers#comment2http://ayende.com/2584/query-building-in-the-domain-service-layers#comment2Thu, 21 Jun 2007 07:51:58 GMTFunny, I have been thinking about the exact same topic. “The single query per controller per request”, is more like a single query per user story step. A simple scenario… User story: Add Item to existing Order Steps: 1 – The user opens an existing order 2 – The user selects an orderline and lookup an item. 3 - The user selects an item from the lookuplist and is return to the order. Where the orderline has been updated with the item. In the ideal world this would be 3 queries and 1 update. However that’s far from how we do it today. What we do now is something like: 1 – Behaviour 1.1 – Query 2 – Update So every query is nested under the behaviour that’s needs it. In order to only do 1 query the only way I could think of doing this, is with serial phase logic: Something like: 1 – Query registration phase 2 – Query phase 3 – Behaviour phase 4 – Update phase Every behaviour element must be able to inform what query it needs. This way the 1 of each type of query can be batched together in a single request to the DB. After that the behaviour operates on the result of the query, and can finally update if needed. This is of cause not a silver bullet, there are problem areas: - Every behaviour now has to inform what queries it uses. Perhaps this could be solved with attributes or AOP? - If the behaviour uses the query data for a logical branch. Ex: If customer gold navigate to special priced goods else navigate to homepage. In this case the query preparation must include both the special priced goods and the data for the homepage, because the behaviour does not yet know if the customer is gold. That’s how far I got… http://ayende.com/2584/query-building-in-the-domain-service-layers#comment1http://ayende.com/2584/query-building-in-the-domain-service-layers#comment1Thu, 21 Jun 2007 07:19:20 GMT