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-repository-pattern.aspx >> >> 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.
