Ayende @ Rahien

Ayende Rahien commented on Querying is a business concern

Fri, 27 Apr 2007 17:50:16 GMT

@Vega, Testing that the criteria is valid / data is valid - usually tested either via in memory database or using integration tests. I like using in memory db for this, or maybe a prepared set of data. I don't feel that mocking gives me much here, because I want to test that the final query is correct, no just its construction.

vega commented on Querying is a business concern

Thu, 26 Apr 2007 23:50:19 GMT

I am swayed by your point and can see how querying could fit naturally in the domain.However, I do have questions regarding how it can be done if using TDD (or anything similar). How would you unit test/develop an individual domain class if you are using the query criteria inside of it ? If we were using your NHQG would we mock the query objects themselves or leave their concrete dependencies in them? Also, how do you validate the data results itself from the database request if the criteria logic is outside of the data access layer (Repository)? Would you even need to? Would we use integration tests later instead?

Jeremy D. Miller -- The Shade Tree Developer commented on Querying is a business concern

Mon, 19 Mar 2007 21:29:04 GMT

Just to get this out of the way, here is my recap from the MVP summit. You will find something to argue

Jake commented on Querying is a business concern

Fri, 09 Mar 2007 21:26:26 GMT

@ Ayende Wow! I did throw a major wobbly there. I misread an earlier comment and overreacted! Never mind... and thanks for deflating my rant! ;-)

Ayende Rahien commented on Querying is a business concern

Fri, 09 Mar 2007 20:50:43 GMT

@Jake, Why the sigh? And I don't think that I am even touching about the subjects that you are talking about.

Jake commented on Querying is a business concern

Fri, 09 Mar 2007 20:40:09 GMT

This is political football between the relational and the object oriented crowds. There are times for both, depending on business requirements and supporting technologies used or available. The difference of the paradigms are similar to the difference between expressing something in base 2 and in plain old ascii. Whereas my email may be transmitted in base 2, I would want to write my friend a string of bits. So, relational access is like base 2. It can represent anything, but may take a whole lot of bits (or in relational terms, joins) to encode complex ideas. Some truisms: Relational access = just data, no behavior = no intent in stored data = relationships can be made adhoc = more generalized = data can outlive an application or be used in ways unintended Object access = data + behavior = intent for data = context specific = relationships are domain driven = data can be navigated naturally The relational folks tend to think that the universe should fit nicely into a RDB schema, and all things should be viewed through the a SQL lens. However, reality is that data is stored in a multitude of organic ways and typically accessed for specific contexts. That's why, When possible, I prefer coding to the repository philosophy. It's the best of both worlds because it is an abstraction of a datastore that has organic accessibility. It can be retargeted to match whatever the actual storage technology the business chooses, be it relational or otherwise. This is a Good Thing. Take a look at MS's LINQ efforts. LINQ formalizes a generalization/abstraction of querying semantics that gets retargeted to a concrete query expressions for the various storage APIs. BAM! You got peanutbutter in my chocolate! :-)

Ayende Rahien commented on Querying is a business concern

Fri, 09 Mar 2007 17:34:48 GMT

The Repository object _is_ the database, as far as I am concerned. What you saw eventually transalate to: select action.Id, action.Name, ... from Actions action where action.Status != 5243 order by action.Date, action.Importance

PVV commented on Querying is a business concern

Fri, 09 Mar 2007 17:26:19 GMT

>CreateCriteria(typeof(MyBusinessEntity)) >.SetProjection(Projections.RowCount()) >.UniqueResult(); >NH 1.2 only, though Oh! Thanks!!!!!! I will investigate this way! In this time I using NH 1.0.2, and I can' t use version 1.2 in my application because it's beta version :-( and I and my customer can not use beta's of any frameworks in my applications. I'm very attentively watching for any additionals features in NH 1.2. It's have got many interesting and very useul features for me ! But by the way thanks!! I'm very appreciative to you! :-)

Jeff Perrin commented on Querying is a business concern

Fri, 09 Mar 2007 16:47:24 GMT

Maybe I'm having some difficulty understanding you here, Oren, but I'd disagree with how you've "expressed your business logic in code". You're 100% right that nHibernate lets you think in terms of the domain, rather than in queries, but the example you've provided is the exact same thing, except you're querying a repository object instead of a database. I'd write it differently myself (the code would look as close to how the user would think about it, so without knowing the exact requirements this won't be perfect): public class User{ public List GetIncompleteActions( IComparable c ){ return Actions.Find(delegate( return a.Status != ActionStatus.Complete; )).Sort(c); } public List Actions{ return _actions; } }

Ayende Rahien commented on Querying is a business concern

Fri, 09 Mar 2007 16:09:07 GMT

Yes, you can: CreateCriteria(typeof(MyBusinessEntity)) .SetProjection(Projections.RowCount()) .UniqueResult(); NH 1.2 only, though

PVV commented on Querying is a business concern

Fri, 09 Mar 2007 15:58:31 GMT

With criteria API as I know I can't create query like this HQL "select count(e.) from MyBusinessEntity as e where [ different search criterias]" and this query must evaluated on the DBMS server not on Application Server, using method IQuery.UniqueResult(). With Criteria API I can implement this query like "CreateCriteria(typeof(MyBusinessEntity)).LIst().Count"; but evaluating this criteria query on my APP server is unacceptable for me bacause I need fetch many instances of class on app server and only after that count all of them; If you know other way, without fetching instances of classes on APP server, I will be very appreciative you, if you should tell me about this way. :-)

Ayende Rahien commented on Querying is a business concern

Fri, 09 Mar 2007 15:22:59 GMT

Why not use the criteria API for this? This is what it was meant for.

PVV commented on Querying is a business concern

Fri, 09 Mar 2007 15:16:09 GMT

>I prefer to use named queries over inline HQL. I agree with you but when i have set of criteras for search for example some like this (i use public props in this code for exampe purposes only in read apps i use only access through properties ) class Crit { public int? _AccountId; public int? _CurrencyId; public string _CompanyName; public string _TransferPurpose; public string _CustomerName; ... } and i need dynamically generate HQL query depended on fields witch valuse !=null/ Other way is used HQL query for all combinations of fields. May be exist any other ways but i don't know their. :-(

Doug Mayer commented on Querying is a business concern

Fri, 09 Mar 2007 14:18:03 GMT

I couldn't agree more. How do you blog so much? I can hardly keep up doing my job and reading your blog throughout the day! It doesn't help that you have some other great minds reading and commenting on your posts. =)