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 <[email protected]> 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
> <[email protected]>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 <[email protected]>
>
> >>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
> >> <[email protected]>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 <
> >>> [email protected]> 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 <[email protected]>
>
> >>>> 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" <[email protected]>
> >>>>> 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 [email protected]>
>
> >>>>> > 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 [email protected]> wrote:
>
> >>>>> > > Hi all.
>
> >>>>> > > In NHibernate in Action, last chapter, the authors present the
>
> >>>>> > > GenericDAO 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.
>
> >>>>> > --
>
> >>>>> > You received this message because you are subscribed to the Google
> >>>>> Groups "nhusers" group.
>
> >>>>> > To post to this group, send email to [email protected].
>
> >>>>> > To unsubscribe from this group, send email to
> >>>>> [email protected].
>
> >>>>> > For more options, visit this group at
> >>>>>http://groups.google.com/group/nhusers?hl=en.
>
> >>>>> > --
>
> >>>>> > You received this message because you are subscribed to the Google
> >>>>> Groups "nhusers" group.
>
> >>>>> > To post to this group, send email to [email protected].
>
> >>>>> > To unsubscribe from this group, send email to
> >>>>> [email protected].
>
> >>>>> > For more options, visit this group at
> >>>>>http://groups.google.com/group/nhusers?hl=en.
>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "nhusers" group.
> >>>>> To post to this group, send email to [email protected].
> >>>>> To unsubscribe from this group, send email to
> >>>>> [email protected].
> >>>>> For more options, visit this group at
> >>>>>http://groups.google.com/group/nhusers?hl=en.
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "nhusers" group.
> >>>> To post to this group, send email to [email protected].
> >>>> To unsubscribe from this group, send email to
> >>>> [email protected].
> >>>> For more options, visit this group at
> >>>>http://groups.google.com/group/nhusers?hl=en.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "nhusers" group.
> >>> To post to this group, send email to [email protected].
> >>> To unsubscribe from this group, send email to
> >>> [email protected].
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/nhusers?hl=en.
>
> >> --
> >> Fabio Maulo
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "nhusers" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected].
> >> For more options, visit this group at
> >>http://groups.google.com/group/nhusers?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhusers" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group at
> >http://groups.google.com/group/nhusers?hl=en.
>
> --
> Fabio Maulo
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
