GenericDAO as in NHibernate in Action?

[Marcello Esposito]

Hi all.

In NHibernate in Action, last chapter, the authors present the
GenericDAO<T, ID> pattern.

It looks very clean to me.

When approaching to write a brand new architecture for a non-trivial
information system, would you systematically use this pattern for all
the involved persistent classes? Are there some disadvantages in doing
so?

Can this pattern hide NHibernate machinery behind the persistency
layers thus avoiding to completely exploit its functionalities (e.g.
ToFuture())?

Thanks in advance,
marcello esposito.

[Marcello Esposito]

No answers. Mmmhh.

I mean: do you use in your programs the GenericDAO<T, ID> (e.g. var
dataSource = (new someEntityDAO()).GetRightEntities())?

Or do you prefer to directly write in your (Web)Forms code like:

var dataSource = CurrentSession.CreateQuery("from someEntity e
where...");

Thanks again,
marcello.

[José F. Romaniello]

I think Dao and Repository are overrated pattern...
But i don't like to mix my nhibernate stuff with a webform for instance..
so i think the best approach is described by fabio here:
http://fabiomaulo.blogspot.com/2010/07/enhanced-query-object.html

the idea is that you have one class for this specific querying thing.. you test the query against the database, and you test your webform against a mocked IQuerySomething

I've sent this same mail to the list like 25 times this year.... sorry

2011/5/3 Marcello Esposito <esposit...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

[Oyvind....@gmail.com]

I've used the repository pattern for years and find that it works well, but as systems grow I find that changes to your repositories' interfaces can be a bit of a pain. As such I've started moving more towards separating things into commands and queries (I'm not talking about CQRS!) and I think that the Enhanced Query Object that Fabio describes is a great approach to reading data.

On May 3, 2011 1:02pm, "José F. Romaniello" <jfroma...@gmail.com> wrote:
> I think Dao and Repository are overrated pattern...
> But i don't like to mix my nhibernate stuff with a webform for instance..
> so i think the best approach is described by fabio here:
> http://fabiomaulo.blogspot.com/2010/07/enhanced-query-object.html
>
>
> the idea is that you have one class for this specific querying thing.. you test the query against the database, and you test your webform against a mocked IQuerySomething
>
> I've sent this same mail to the list like 25 times this year.... sorry
>
>
> 2011/5/3 Marcello Esposito esposit...@gmail.com>
>
> No answers. Mmmhh.
>
>
>

> I mean: do you use in your programs the GenericDAO (e.g. var

>
> dataSource = (new someEntityDAO()).GetRightEntities())?
>
>
>
> Or do you prefer to directly write in your (Web)Forms code like:
>
>
>
> var dataSource = CurrentSession.CreateQuery("from someEntity e
>
> where...");
>
>
>
> Thanks again,
>
> marcello.
>
>
>
>
> On 28 Apr, 22:22, Marcello Esposito esposito.ma...@gmail.com> wrote:
>
> > Hi all.
>
> >
>
> > In NHibernate in Action, last chapter, the authors present the
>

> > GenericDAO pattern.

[José F. Romaniello]

Exactly!, it is very related with command and queries separation.. While it is okey and doable to have something generic to CUD (Create/Update/Delete) it is useful to have specific artifacts for queries...
The repository pattern thing to mix both, you end up with few CUD generic or inherited methods  and many queries methods.
And having linq scattered all over the application is not good.

2011/5/3 <Oyvind....@gmail.com>

[Angel Java Lopez]

Hmmmm ... "... the repository pattern thing to mix both... many queries methods" ?

According to:
http://blogs.hibernatingrhinos.com/nhibernate/archive/0001/01/01/the-repository-pattern.aspx

Martin Fowler writes:

"A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers."

In my interpretation, "query specifications" are not related to query methods in repository.

DAO have query methods.
Repository has ONE way/method/whatever that SATISFIES query specifications.

What is the current jargon, definitions for DAOs and repositories?

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

[José F. Romaniello]

Yes, you are right, except than nobody write repositories in that fashion and we tend to mix the two things. All example you will find on the net, they said "repository" while the implementation is a  "dao".

Except me,
please read all this blog post to learn the differences between all the abstractions of Data you can do.. I briefily mention my vision of query pattern which is the same than the EQO object (and it is not the same than MF query object definition). I tried to sumarize all Pros and Cons:
http://jfromaniello.blogspot.com/2010/06/linqspecs-why.html
and i also did this specification library:
http://linqspecs.codeplex.com/

And Fabio Maulo (another guy in the list :) who wrote about the two patterns):
http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html
http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-dao.html

Having said that, i still think than submiting specifications to a repository is not useful and powerful. Because it is still tied to the underlying abstractions (for instance the nhibernate criteria api), unless you use linq or my linqspecs.  Using criteria is worthless why i do want to have the two things separatedly? specification from execution? i am not interested in testing the composition of the query but the execution and results. And linq specifications suffers same problem, i don't want to test specification against an inmemory collection or so... I usually test my queries against a database, so there is no point in separate spec and execution

2011/5/3 Angel Java Lopez <ajlop...@gmail.com>

[Fabio Maulo]

http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-dao.html

http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html

That’s all ? … yes that’s all… or that should be all.

The creation of a GOD LINQ-provider is delegated to the big master Fowler or, if you want, to you.

In the meantime I will use what I have available today and NH has at least 6 ways to write/optimize a query hitting DB.

Fabio Maulo

[José F. Romaniello]

I wrote some examples implementations in gist.github for future reference.
As you can see we already write so many posts on the subject, so i am not planning to write another..
https://gist.github.com/953700 <-- query object (or EQO)
https://gist.github.com/953718 <-- dao with expressions
https://gist.github.com/953721 <-- dao with specific methods
https://gist.github.com/953725 <-- dao with specification pattern (linqspecs.codeplex.com)

2011/5/3 Fabio Maulo <fabio...@gmail.com>

[Fabio Maulo]

There are others ;)

QueryObject based directly on Criteria/QueryOver

QueryObject based on custom DSL as wrapper of Criteria/QueryOver

Specification pattern based directly on Criteria/QueryOver instead on LINQ

[Marcello Esposito]

Thanks to everybody for the useful information.

I studied the EQO pattern and I found it very interesting.

It provides an highly modular approach to plug persistency
capabilities into an application: I need a new query against the
database, then I create a new EQO class. I don't need that query
anymore, then I simply delete the related class (and possibly solve
compilation errors). So, the rest of code is almost not affected.
Nevertheless, it seems quite confortable to collect all the queries in
a project folder, organizing them in a well structured directory tree,
according to the entities involved by queries. Finally, no "monster-
shaped" classes with tons of methods, one for each existing query,
like in ADO approach.

Just two questions.

(i) How should I create an EQO instance?

Do I need a factory? If yes, is such factory a "monster-shaped" class
again (i.e. with a creation method for each existing EQO class)?

(ii) How should I manage the NH session in winform applications?

In the examples I read, EQO uses GetCurrentSession() to fire queries.
How does this mix with the many simultaneously open winform sessions
(i.e. one for each persistency-aware open form).

Currently, trying to solve both the above problems, I'm using the
following approach.

public interface ISomeQueryEQO
{
//...
IList<Something> GetAll();
}

internal class SomeQueryEQO : ISomeQueryEQO
{
private readonly ISession session;
public SomeQueryEQO(ISession session)
{
this.session = session;
}
public SomeQueryEQO() : this(null) { }
public IList<Something> GetAll()
{
var s = (session != null ? session :
NHHelper.SessionFactory.GetCurrentSession());
return s.QueryOver<Something>()...
}
}

public static class EQOFactory
{
public static ISomeQueryEQO CreateSomeQueryEQO()
{
return new SomeQueryEQO();
}
public static ISomeQueryEQO CreateSomeQueryEQO(ISession s)
{
return new SomeQueryEQO(s);
}
}

I'm not sure this is the right approach, and it might hide some
misunderstanding of mine. Sorry for this.

Thanks for your precious help.
Marcello.

On 3 Mag, 20:26, Fabio Maulo <fabioma...@gmail.com> wrote:
> There are others ;)
> QueryObject based directly on Criteria/QueryOver
> QueryObject based on custom DSL as wrapper of Criteria/QueryOver
> Specification pattern based directly on Criteria/QueryOver instead on LINQ
>
> On Tue, May 3, 2011 at 2:41 PM, José F. Romaniello

> <jfromanie...@gmail.com>wrote:

>
>
>
>
>
>
>
>
>
> > I wrote some examples implementations in gist.github for future reference.
> > As you can see we already write so many posts on the subject, so i am not
> > planning to write another..
> >https://gist.github.com/953700<-- query object (or EQO)
> >https://gist.github.com/953718<-- dao with expressions
> >https://gist.github.com/953721<-- dao with specific methods
> >https://gist.github.com/953725<-- dao with specification pattern (
> > linqspecs.codeplex.com)
>

> > 2011/5/3 Fabio Maulo <fabioma...@gmail.com>
>
> >>http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-dao.html
>
> >>http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html
> >>  <http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-dao.html>That’s

> >> all ? … yes that’s all… or that should be all.
>
> >> The creation of a GOD LINQ-provider is delegated to the big master Fowler
> >> or, if you want, to you.
> >> In the meantime I will use what I have available today and NH has at least
> >> 6 ways to write/optimize a query hitting DB.
>

> >> On Tue, May 3, 2011 at 11:27 AM, Angel Java Lopez <ajlopez2...@gmail.com>wrote:
>
> >>> Hmmmm ... "... the repository pattern thing to mix both... many queries
> >>> methods" ?
>
> >>> According to:
>

> >>>http://blogs.hibernatingrhinos.com/nhibernate/archive/0001/01/01/the-...
>
> >>> Martin Fowler writes<http://martinfowler.com/eaaCatalog/repository.html>:
>
> >>> "*A Repository mediates between the domain and data mapping layers,

> >>> acting like an in-memory domain object collection. Client objects
> >>> construct query specifications declaratively and submit them to Repository
> >>> for satisfaction. Objects can be added to and removed from the
> >>> Repository, as they can from a simple collection of objects, and the mapping
> >>> code encapsulated by the Repository will carry out the appropriate
> >>> operations behind the scenes. Conceptually, a Repository encapsulates the
> >>> set of objects persisted in a data store and the operations performed over
> >>> them, providing a more object-oriented view of the persistence layer.
> >>> Repository also supports the objective of achieving a clean separation and

> >>> one-way dependency between the domain and data mapping layers.*"

>
> >>> In my interpretation, "query specifications" are not related to query
> >>> methods in repository.
>
> >>> DAO have query methods.
> >>> Repository has ONE way/method/whatever that SATISFIES query
> >>> specifications.
>
> >>> What is the current jargon, definitions for DAOs and repositories?
>
> >>> Angel "Java" Lopez
> >>>http://www.ajlopez.com
> >>>http://twitter.com/ajlopez
>
> >>> On Tue, May 3, 2011 at 11:07 AM, José F. Romaniello <
> >>> jfromanie...@gmail.com> wrote:
>
> >>>> Exactly!, it is very related with command and queries separation.. While
> >>>> it is okey and doable to have something generic to CUD
> >>>> (Create/Update/Delete) it is useful to have specific artifacts for
> >>>> queries...
> >>>> The repository pattern thing to mix both, you end up with few CUD
> >>>> generic or inherited methods  and many queries methods.
> >>>> And having linq scattered all over the application is not good.
>

> >>>> 2011/5/3 <Oyvind.Vall...@gmail.com>

>
> >>>> I've used the repository pattern for years and find that it works well,
> >>>>> but as systems grow I find that changes to your repositories' interfaces can
> >>>>> be a bit of a pain. As such I've started moving more towards separating
> >>>>> things into commands and queries (I'm not talking about CQRS!) and I think
> >>>>> that the Enhanced Query Object that Fabio describes is a great approach to
> >>>>> reading data.
>

> >>>>> On May 3, 2011 1:02pm, "José F. Romaniello" <jfromanie...@gmail.com>

> >>>>> wrote:
> >>>>> > I think Dao and Repository are overrated pattern...
> >>>>> > But i don't like to mix my nhibernate stuff with a webform for
> >>>>> instance..
> >>>>> > so i think the best approach is described by fabio here:
> >>>>> >http://fabiomaulo.blogspot.com/2010/07/enhanced-query-object.html
>
> >>>>> > the idea is that you have one class for this specific querying
> >>>>> thing.. you test the query against the database, and you test your webform
> >>>>> against a mocked IQuerySomething
>
> >>>>> > I've sent this same mail to the list like 25 times this year....
> >>>>> sorry
>

> >>>>> > 2011/5/3 Marcello Esposito esposito.ma...@gmail.com>

[Fabio Maulo]

NHibernate 3.0 cookbook chapter 3 pages 78, 94