This would actually been my next question :)
usually I would do the same thing you talk about and encapulate the
quiery, but from what I understand with DDD (not saying that this only
goes for DDD, i have just never heard before I started on DDD), you
are allowed to make this sort methods.
using the Criterion as a parameter for method like the FindOne(),
seems to follow the guideline/rule of the SPECIFICATION Pattern and
thereby add flexiblity to the design.
The argument to us the FindMeSomething(iNeed) and thereby making hard-
coded quires, should be that the client would have done this anyway.
So it makes sense to make hardcoded quires because they give you some
convience
But the issue with FindMeSomething(iNeed), is that the developer need
to understand the inner workings/implications of using a encapsulated
metod... meaning that, if they dont know about how the method quiries
the database, they might pull to much data into memory and thereby
bringing the system down.
you could probably refactor yourself out of this problem, but still...
/Mark
On Jan 26, 3:55 pm, Markus Zywitza <markus.zywi...@gmail.com> wrote:
> Code from the article you linked:
>
> public virtual T FindOne(params ICriterion[] criteria)
> {
> return ActiveRecordMediator<T>.FindOne(criteria);
> }
>
> This moves the responsibility for creating a particular query from the
> repository to the higher layers, who need to know about an aggregate's
> inner workings. Once you start to optimize for n+1 etc., this
> knowledge of the persistence is rather deepened than encapsulated.
> A better approach is to create a bunch of
> FindByWhateverMyAppNeeds(string iNeedThat). That's ugly, but
> encapsulates persistence within the repository.
>
> -Markus
>
> 2009/1/26 Mark Jensen <don...@gmail.com>:
>
>
>
> > Hi Markus
>
> > Could you explain the contradictions a bit more for me?
>
> > thanks :)
>
> > On Jan 26, 1:22 pm, Markus Zywitza <markus.zywi...@gmail.com> wrote:
> >> You lose nothing with dropping ActiveRecordBase but convenience.
>
> >> But keep in mind:
>
> >> 1) AR classes without ARBase make good DTOs, but still bad domain classes.
> >> 2) Generic repositories are an antipattern. A repository should
> >> encapsulate the knowledge of an aggregate's persistence details. That
> >> contradicts with ready-to-use-plugs for LINQ or criteria queries.
>
> >> If you need to do DDD, use AR as DTO and map it to the domain layer.
> >> If you are doing this because DDD has a momentary hype, just don't do
> >> it at all. The "Domain Model" is not the only enterprise pattern that
> >> yields maintainable software.
>
> >> -Markus
>
> >> 2009/1/26 Mark Jensen <don...@gmail.com>:
>
> >> > Hi
>
> >> > From what i can read on the internet people do really like this
> >> > combination due to the placement of the persitance logic.
>
> >> > how ever, i know that Castles AR has something callsed
> >> > ActiveRecordMediator which seems to be the solution to the problem
> >> > above. (i also know ayendes rhino commons which also have an
> >> > implementation of the repository pattern).
>
> >> > The questions are.
>
> >> > 1. Will i lose something if i stop inheritting from ActiveRecordBase
> >> > and use ActiveRecordMediatior instead? (to me it seems like i will get
> >> > a lot more functionality/control)
>
> >> > 2. Can someone me how to implement the Repository pattern with
> >> > ActiveRecordMediator. I have found this example here
> >> >http://www.lostechies.com/blogs/johnteague/archive/2008/05/27/using-d...
>
> >> > but to me it seems like I would have to make a Repository (and inherit
> >> > from BaseRepository) for every Aggregate and then I need to
> >> > instantiate the Repository it when i want to use it.
>
> >> > Is there a better way of doing this?
>
> >> > :)
>
> >> > best regards,
> >> > Mark
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to castle-project-users@googlegroups.com
To unsubscribe from this group, send email to
castle-project-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
