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/
posted by survic at
10:18 PM
1 Comments:
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.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home