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 <[email protected]> > 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. > -- 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.
