Tuesday, March 13, 2007

Summary of my comments on CSLA and DDD

1. Finally I heard similar voice:
http://www.avocadosoftware.com/csblogs/dredge/archive/2007/01/28/681.aspx

http://www.avocadosoftware.com/csblogs/dredge/archive/2007/02/19/687.aspx

>>>> And as a side note, the largest problem that I have with CSLA is the idea that an entity contains it’s own data access code (commonly called the “Active Record” pattern). That in combination with the force parent-child relationships… both of those still bug the crap out of me and I’ll never use a pure version of CSLA because of them. I’m more comfortable having the data access code split out into it’s own class so that I can do dependency injection, and there-by enable TDD in my CSLA based applications.

>>>> Fortunately for me and my team, I have known the limitations of the stock CSLA framework for quite some time, and have created a highly modified version of the v2.0 CSLA framework for our use. My changes essentially, have been to remove the forced parent-child relationship and also to completely remove the DataPortal.
Note that removing “Dataportal” means taking out CRUD 4 method limitations; also, removing “forced parent-child relationship” points to removing “strongly typed collections”.


2. My suggestion for using CSLA the right way: http://forums.lhotka.net/forums/2/11975/ShowThread.aspx
(also, see my recent blogs)

3. Heated discussion about CSLA and DDD:

http://codebetter.com/blogs/jeremy.miller/archive/2007/02/23/Don_2700_t-Let-the-Database-Dictate-Your-Object-Model.aspx?CommentPosted=true#commentmessage


4. Another CSLA review
http://swcses.eponym.com/blog/_archives/2007/1/5/2622285.html


5. Similar voice on DDD:

http://weblogs.asp.net/fbouma/archive/2006/08/23/Essay_3A00_-The-Database-Model-is-the-Domain-Model.aspx

http://blog.springframework.com/arjen/archives/2006/10/10/domain-drivel/

1 Comments:

Anonymous Anonymous said...

survic (myself!):

You may say my definition of "Rich model" is too strict. Well, honest is honest! Here is a quote:



...a concrete example.

Suppose you have a Customer object. In the domain, the Customer has an Account, but in the object model, a Customer object only has a reference to its Account's id (following the notion of an aggregate root in domain driven design).

Now suppose the service layer supports the method getNetWorth(Customer). Without a rich domain object, the service would be responsible for retrieving the Account object on behalf of the Customer object and returning the value of the Account. Something like this:

...
Account account = accountRepository.getAccount(customer.getAccountId();
return account.getValue();
...

But suppose we want this logic to exist in the Customer object, as it should with a rich domain model. How would the Customer object obtain a reference to its Account object? The answer is it needs access the AccountRespository, And AspectJ + Spring can help achieve this. Basically, an AspectJ aspect (woven into the Customer class) would be invoked that would inject the AccountRepository bean from the Spring context whenever a Customer object in instantiated.


For deails, read the link:

http://ryanbreidenbach.blogspot.com/2006/09/spring-ddd-and-aspectj-example.html

Now, I believe I can give DDD a break now. I will not say a single bad word about DDD from now on. promise.

3/13/2007 10:47:00 PM  

Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home