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.
