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.
