Tuesday, March 13, 2007

Summary of my comments on CSLA and DDD

1. Finally I heard similar voice:


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


4. Another CSLA review

5. Similar voice on DDD:




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:


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]

<< Home