Ayende @ Rahien

Chris Tavares commented on Making the complex trivial: Rich Domain Querying

Thu, 30 Oct 2008 21:01:51 GMT

Then the JSON serializer is busted.

Ayende Rahien commented on Making the complex trivial: Rich Domain Querying

Mon, 27 Oct 2008 06:09:31 GMT

Chris, It _works_.

Chris Tavares commented on Making the complex trivial: Rich Domain Querying

Mon, 27 Oct 2008 05:16:40 GMT

Just a minor nit to pick - your JSON is invalid. You're required to quote all strings, including the ones on the left of the ':' characters.

Neil commented on Making the complex trivial: Rich Domain Querying

Thu, 23 Oct 2008 10:39:32 GMT

Hi Oren, I'm sure I saw some code like this in a pub recently :) Thanks for putting it up on the blog.

JP commented on Making the complex trivial: Rich Domain Querying

Tue, 21 Oct 2008 10:32:32 GMT

Thanks! You're the man.

Ayende Rahien commented on Making the complex trivial: Rich Domain Querying

Sun, 19 Oct 2008 14:45:52 GMT

It is something like: public T[] FindAll(AbstractSearchFilter filter) { var dc = DetachedCriteria.For

JP commented on Making the complex trivial: Rich Domain Querying

Sun, 19 Oct 2008 14:16:41 GMT

I'm just not getting what you intend to do in the FindAll method. You receive an AbstractSearchFilter as a parameter but I cannot understand what you do in the method's body :) Can you please reply how you think this method should behave? Thanks

Ayende Rahien commented on Making the complex trivial: Rich Domain Querying

Sun, 19 Oct 2008 11:52:48 GMT

Please ask in nh users group

JP commented on Making the complex trivial: Rich Domain Querying

Sun, 19 Oct 2008 11:27:35 GMT

Can you please show an example using the code above?

Ayende Rahien commented on Making the complex trivial: Rich Domain Querying

Sun, 19 Oct 2008 11:22:55 GMT

JP, You are using CreateCriteria to do this

JP commented on Making the complex trivial: Rich Domain Querying

Sun, 19 Oct 2008 11:07:59 GMT

Sorry my ignorance but how do you pass the list of actions to a single detachedcriteria? In other words, if you have a repository which accepts a single detachedcriteria, how do you merge them all to a single one?

Grimace of Despair commented on Making the complex trivial: Rich Domain Querying

Fri, 17 Oct 2008 23:34:35 GMT

I smell a NHQG update + revival :) (I know, I know, ... I'm free to send a patch :P )

Ayende Rahien commented on Making the complex trivial: Rich Domain Querying

Fri, 17 Oct 2008 20:07:16 GMT

MD, What do you mean safe? From SQL injection perspective, NH ensure that this is not a problem. From optimization perspective, your filter model ensure that you don't allow truly bad things happening.

MD commented on Making the complex trivial: Rich Domain Querying

Fri, 17 Oct 2008 18:26:44 GMT

It is cool indeed, but is it safe to build the search criteria on the client?

pete w commented on Making the complex trivial: Rich Domain Querying

Thu, 16 Oct 2008 18:24:35 GMT

I've done this kind of thing before, both in and out of NHibernate. I have found to to be quite useful. What I would love to see is a technology that provides a sql server reporting services interface, but works with business objects and not sql, to me this would be a killer app. All too often, we create applications with rich business objects, only to write sql-based reports, to me, it makes more sens to re-use these object for reporting

Ayende Rahien commented on Making the complex trivial: Rich Domain Querying

Thu, 16 Oct 2008 16:11:04 GMT

Dennis, You missed the point of complexity, it is not in the actual querying. It is the query building part that is hard.

Demis commented on Making the complex trivial: Rich Domain Querying

Thu, 16 Oct 2008 10:02:26 GMT

hmmm. This just seems like a lot of effort for something Linq would excel at.

Ken Egozi commented on Making the complex trivial: Rich Domain Querying

Thu, 16 Oct 2008 08:18:39 GMT

Cool thing. Never used JSON serialisation for that, usually I'll send the query in Form/Querystring and use the [DataBind] power to get the filter. My only problem with it, is that the filters (which are domain related) become way too aware of NH imo. I don't like my IReopsitory methods to accept NH based things as parameters What I do is to have the Filter as a an anaemic NH-free class, located within the Domain. in the domain implementation assembly (where the NH stuff goes) I'd declare a type inheriting from DetachedCriteria, that accepts the filter in the constructor. public class ModuleSearchCriteria : DetachedCriteria { private readonly ModuleSpecification specification; ///

public ModuleSearchCriteria(ModuleSpecification specification) : base(typeof(Module), "module") { // manipulating the criteria by the filter } That way it's also easy to de-serialise a filter to a view (say for the sake of pre-populating a search screen), using the filter, keeping the view free from NH dependant objects

Brian Chavez commented on Making the complex trivial: Rich Domain Querying

Wed, 15 Oct 2008 22:48:01 GMT

I did something similar to this in a recent project using JSON to serialize search criterias. Except, I didn't put the criteria building in the property setters. They're like SearchDTO objects. The DAOs themselves take care of translating the filter objects into their respective DetachedCriterias to avoid SearchObjects and UI dependent on NHibernate.dll.