@Cesar - You're welcome. When you define your queries as methods on a repository, you end up with a messed up DAO, not a repository. Personally, I don't see anything wrong with DAOs, but you should be explicit about it. "Is this a repository or a DAO?"
This may not be entirely accurate, but based on my limited understanding of true repositories, you should strive for one repository per aggregate root, not one repository per entity type. If you only have a CustomerRepository, where would you put your order queries? http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/08/19/ddd-repositories-and-orms.aspx On Mon, Sep 7, 2009 at 11:25 AM, Cesar Sanz <[email protected]>wrote: > @Jason, > > Thanks for replying. > > I already saw this > http://ayende.com/Blog/archive/2009/04/17/repository-is-the-new-singleton.aspx > > This is why I asked this question. The point I see is, that if I must to > write a class for every query I must to perform, so > I will have dozen of classes of this kind.. Instead, with a repository I > will have just one reporitory for many queries.. > > But, Why is better to have many QueryObjects instead of a single > repository..?? > > Thanks. > > ----- Original Message ----- > > *From:* Jason Dentler <[email protected]> > *To:* [email protected] > *Sent:* Monday, September 07, 2009 9:12 AM > *Subject:* [nhusers] Re: Query Object Pattern > > Cesar, > I'm actually going to cover this in a blog post I'm writing today, but I'll > summarize it for you: A lot of very smart people don't agree, so analyze > your particular situation and use what you think will work best for you. > > As for a full working example of query objects, I can't help, but you might > get some good ideas here: > > http://ayende.com/Blog/archive/2009/04/17/repository-is-the-new-singleton.aspx > > > http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/ > > Jason > > On Mon, Sep 7, 2009 at 9:39 AM, Cesar Sanz <[email protected]>wrote: > >> >> Hi, I asked something similar under the topic "QueryObjects vs Repository" >> Can somebody please explain me which is better and why.. >> >> Also I want to know if you have any working example of Query Objects. >> >> Regard >> >> ----- Original Message ----- >> From: "Ricardo Peres" <[email protected]> >> To: "nhusers" <[email protected]> >> Sent: Monday, September 07, 2009 2:04 AM >> Subject: [nhusers] Re: Query Object Pattern >> >> >> >> Are there any good examples of query classes, other than specification >> (which are already implemented, for example, in NCommon)? >> There are two different scenarios, I believe: >> >> - If there is need to cross application domains (e.g., web services or >> remoting) >> - If not >> >> What would such a class look like? >> >> Thanks, >> >> RP >> >> On Sep 7, 2:36 am, Bevan Arps <[email protected]> wrote: >> > > In your opinion, which is the best way to implement the query object >> > > pattern: >> > >> > > 1) by using IQueryable/IQueryable<T> >> > > 2) by using ICriteria/DetachedCriteria >> > > 3) custom classes >> > >> > > What I mean is, assuming that we have an object that stores query >> > > parameters (page size, page index, filters, etc) that goes all the way >> > > to the presentation layer, which is the better option for doing so, so >> > > that it is possible to enhance the original query? >> > >> > As soon as you need to cross a process boundary - from an application >> > server to a client, or from webserver to browser - anything that >> > depends on IQueryable or ICriteria is going to have associated >> > "baggage" that becomes a liability. >> > >> > Having a custom class gives you a lot more control over how this plays >> > out. There are a myriad of patterns you *could* follow - in your >> > shoes, I'd start with the "Specification" pattern and branch out if >> > that didn't work for me. >> > >> > Just my 2c. >> > Bevan. >> >> >> >> > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
