Re: How to do DDD + AR (repositories)

2009-01-29 Thread Mark Jensen

I appreciate you taking the time to blog your experience with this
topic :)

/Mark

On Jan 27, 3:35 pm, Markus Zywitza markus.zywi...@gmail.com wrote:
 ICriteria relates to Specification like ActiveRecord-types to a domain
 model. ICriteria may resemble a specification, but it is actually a
 query in a fluent API format. If you want to go all the way, then you
 need a real specification model that is used to create queries by the
 repository.

 Also, I blogged about my experiences with AR+DDD. You might find it
 useful for your own decision what to do.

 http://mortslikeus.blogspot.com/2009/01/active-record-and-ddd.html

 -Markus

 2009/1/27 Mark Jensen don...@gmail.com:



  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 ActiveRecordMediatorT.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
-~--~~~~--~~--~--~---



Re: How to do DDD + AR (repositories)

2009-01-27 Thread Mark Jensen

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 ActiveRecordMediatorT.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
-~--~~~~--~~--~--~---



Re: How to do DDD + AR (repositories)

2009-01-27 Thread Markus Zywitza

ICriteria relates to Specification like ActiveRecord-types to a domain
model. ICriteria may resemble a specification, but it is actually a
query in a fluent API format. If you want to go all the way, then you
need a real specification model that is used to create queries by the
repository.

Also, I blogged about my experiences with AR+DDD. You might find it
useful for your own decision what to do.

http://mortslikeus.blogspot.com/2009/01/active-record-and-ddd.html

-Markus

2009/1/27 Mark Jensen don...@gmail.com:

 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 ActiveRecordMediatorT.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
-~--~~~~--~~--~--~---



Re: How to do DDD + AR (repositories)

2009-01-26 Thread Colin Ramsay
Well you wouldn't necessarily have to make a repo for every entity because
you'd have a generic RepoT you could use. However you might create (as an
example) a UserRepo : BaseRepoUser with a FindByUsername method as a
little syntactic sugar.

I think many people would use a container such as windsor to avoid having to
manually instantiate their repositories.

On Mon, Jan 26, 2009 at 11:02 AM, Mark Jensen don...@gmail.com wrote:


 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-database-repository-pattern-with-activerecord-with-activerecordmediator.aspx

 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
-~--~~~~--~~--~--~---



Re: How to do DDD + AR (repositories)

2009-01-26 Thread Markus Zywitza

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-database-repository-pattern-with-activerecord-with-activerecordmediator.aspx

 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
-~--~~~~--~~--~--~---



Re: How to do DDD + AR (repositories)

2009-01-26 Thread Victor Kornov
This cries for at least to mention those other patterns.

On Mon, Jan 26, 2009 at 3:22 PM, Markus Zywitza markus.zywi...@gmail.comwrote:


 The Domain Model is not the only enterprise pattern that
 yields maintainable software.



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: How to do DDD + AR (repositories)

2009-01-26 Thread Mark Jensen

:)

so you would also do something like the example from the link shows,
but just remove the FindAll ?

On Jan 26, 12:20 pm, Ken Egozi egoz...@gmail.com wrote:
 my take:
 externally the domain API will expose specialised repositories for aggregate
 roots. (not all of them should have Save, and a generic FindAll is not
 informative imo)
 internally, in the repository implementations, they'd use ARMediator (or NH
 queries) to retrieve manipulate data



 On Mon, Jan 26, 2009 at 1:08 PM, Colin Ramsay colinram...@gmail.com wrote:
  Well you wouldn't necessarily have to make a repo for every entity because
  you'd have a generic RepoT you could use. However you might create (as an
  example) a UserRepo : BaseRepoUser with a FindByUsername method as a
  little syntactic sugar.

  I think many people would use a container such as windsor to avoid having
  to manually instantiate their repositories.

  On Mon, Jan 26, 2009 at 11:02 AM, Mark Jensen don...@gmail.com wrote:

  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

 --
 Ken 
 Egozi.http://www.kenegozi.com/bloghttp://www.delver.comhttp://www.musicglue.comhttp://www.castleproject.orghttp://www.gotfriends.co.il
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: How to do DDD + AR (repositories)

2009-01-26 Thread Mark Jensen

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
-~--~~~~--~~--~--~---



Re: How to do DDD + AR (repositories)

2009-01-26 Thread Markus Zywitza

Code from the article you linked:

public virtual T FindOne(params ICriterion[] criteria)
{
return ActiveRecordMediatorT.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
-~--~~~~--~~--~--~---