+972 52-548-6969
StoryVerse (and very cool search technique)
time to read 2 min | 203 words
StoryVerse is an agile management web application, based on MonoRail & Active Record. The UI is very googlish in nature, and I really like it. Still very early in the project, but showing a lot of promise.
The way that the guys from LunaVerse are using the criteria objects had me scratching my head for a while, until I saw how it is used on the controller, then I had a "Wow! That is cool!" momemt.
Here is a sample:
public void SearchProject([DataBind("project")] ProjectSearchCriteria projectSearchCriteria)
{
PropertyBag["projects"] = Project.FindAll( projectSearchCriteria.ToDetachedCriteria() );
}
{
PropertyBag["projects"] = Project.FindAll( projectSearchCriteria.ToDetachedCriteria() );
}
You really need to check out the code in order to appriciate it. It is like placing a lot of domino pieces and watching them all fall into places, no extra work required. Here is one technique that I am so going to take advantage of next time I am going to write a search screen.
Comments
Sounds like a great thing to link to from http://using.castleproject.org.
It is a wiki, create an account and do it :-)
done.
Care to elaborate to the coolness of this?
Not everyone understands what's going on in that piece of code.
Roy.
ProjectSearchCriteria is a class that has properties such as From, To, UserName, etc.
The coolness factor is that they are filled automagically by the [DataBind] property.
Since the properties setter build the criteria directly, this means that the whole complexity of the search form was reduce to a very small problem of just executing the criteria.
A very easy way to handle the problem
Way cool! I already used [DataBind] to fill some DTO, but never though on using it to fill a clever object that can generate a Criteria ;)
Very good SOC.
First, thanks for the kind comments.
This pattern has been evolving. It began in a prior (non ActiveRecord) project. In that version we passed our custom criteria object into a repository method which then built HQL and passed it on to our data gateway.
The newer approach, reflected in StoryVerse, is nice for a couple of reasons. First, it uses strongly typed ICriteria instead of HQL. Also, it's nice to encapsulate the creation of Nhib criteria inside the custom criteria class. Thus the class could be easily extended to support other gateway implementations. For example, you could add a ToSql() method or perhaps something like ToLinqQuery() ???
Recently we have improved on this pattern by coupling custom criteria objects with Dto objects. We added a property to the criteria class, ReturnType, with values of "Entity" and "Dto." When the return type is Dto, we use AliasToBeanResultTransformer to automagically return a list of Dtos instead of root entities.
I was planning to write an article soon that demonstates this newest rendition of the pattern. However, we're having a problem that appears to be an NHibernate bug, described here: http://forum.hibernate.org/viewtopic.php?t=973951&highlight=alias
Comment preview