more about CSLA and DDD

------------------my comments on http://swcses.eponym.com/blog/_archives/2007/1/5/2622285.html

by survic on Sat 10 Mar 2007 11:35 PM CST Permanent Link

vikas put the link of my blogs here above. So, I have to say something here now.

I would like to say something on the other side that you and Rocky both agree.

I read DDD many times, and I used CSLA for a long time (but you may say I bite the feeding hands, I criticize it harshly), and I used Java for a long time, while simultaneously used VB3-6 along the way.

I mentioned Java, because please do not say that I do not know OO.

My argument is that DDD, yours stand, and CSLA are all antique OO. ADM (anemic domain model) is a good compromise for modern distributed computing which is necessary for modern OO. Modern OO must be ADM!

For a large scale enterprise computing, ADM is the must. If you use “rich” antique OO, you are in big trouble.

To learn modern OO, the best way is to use nhibernate or other good OR mapping tool. Also, study java’s entity bean. Entity bean is the first mainstream OR mapping concept, it sucks; however, its key concepts are fine. Here is my recent DDD blog: http://survic.blogspot.com/2006/07/domain-driven-design-data-modeling-as.html

-------------------------Joseph's reply

by Joseph Reddy on Mon 12 Mar 2007 01:26 PM CDT | Profile | Permanent Link
Survic,

You are touching on many subjects here. The most interesting of which is this idea of “Antique OO” vs “Modern OO” with Modern OO embracing an Anemic Domain Model. For the sake of only trying to tackle one point at a time, I don’t care to argue whether one design is better than the other.

There is something wrong with stripping the most basic OO principles from a design and then calling it “object-oriented.” What you are calling Modern OO is a data-centric design with procedural code using objects that abstract the database. Again, I’m not here to argue against this approach, only to note that it is not an object-oriented approach. The ADM is a completely different kind of design where objects are no longer the focal point of the application, rather, they exist simply to get data in and out of the database.


--------------------------------my reply's reply
Reply
Re: Re: Re: Re: Book Review: Expert C# Business Objects: Rockford Lhotka: Part Deux
by survic on Tue 13 Mar 2007 12:35 AM CDT | Permanent Link
1. The huge part of my argument is actually not technical, it is perspective. If you really talk to “strategic” users (stake holders), do they really care the “Applications”? no! They care about the data! All those “enterprise modeling”, “data warehousing”, all major enterprise level initiatives, they are all about data, not applications.

2. It is almost a zigzag way: (a) small vb6 (“data centric”), (b) advanced VB6 and some .net (and some confused lightweight java) – antique OO (“behavior centric”, OO purist, DDD, antique OO), (c) enterprise java (both heavy and lightweight) and advanced .net (“modern OO”, “SOA”).


3. The key idea is that it is inevitable that “services” and “DAOs” must be separated from “entities”, and “entities” must have no dependency on services and Daos. This rule is extremely important for distributed computing. This links to a very good post by ayende: http://ayende.com/Blog/archive/2007/02/27/Entities-Services-and-what-goes-between-them.aspx


4. Once you comply the above rule, then, the so called “business logic” within entities is extremely constrained, and therefore ‘anemic”. They are rightly so. There is no way out of it.

5. Those “services” and “DAOs” are obviously procedural.

6. However, entities are OO, they are just “anemic”. So, together with services and Daos, the whole thing is still OO (but not rich OO, see below).

7. It is cheating to say a model that complies the above a “rich model”. If you split “services” and “DAOs” away from “entities”, then, the model is not “rich" anymore. Please do not misleading people!

8. You may say, it is just word game. No, it has direct practical implications. One of it is using OR mapping. If you are willing to use a OR mapping tool and feel it is satisfactory (not perfect, the whole thing is to find a good compromise, trade off) to call it OO, then, you are with me; otherwise, you are against me ;-) Seriously, OR mapping is a key test stone.

9. Note that I am not saying you actually need to use OR in every project, just conceptually is enough.

10. Another thing is that, once you really know OR mapping for quite a while, you will appreciate that really the soul of behaviors is data. Further, for entities, most of the time, the deepest and most appropriate (e.g., keep it simple) objects are indeed relational, not fancy design patterns. Also, OR mapping rules take care of inheritance-relational mappings. For enterprise computing, for entities (not infrastructure coding), “keep it simple” is the most important thing. And the core of “keep it simple” is to “keep it close to relational! Note that keep it “relational” does not mean “keep it like database tables”, because tables can be de-normalized etc.


11. The so-called “logic intensive classes" is simply misleading. Keep those logic in methods. If really necessary, create some help entities, that is not big deal. Remember, enterprise computing is easy, modern OO is easy, algorithm is easy – procedural algorithm is easy, using design patterns to do it is also easy. It is not that big deal. As a result, do not over use design patterns in algorithms. Because it is easy, so, do not show off. if you really need to show off, find a infrastructure project! I studied DDD carefully, I find that if you use “keep it simple and relational”, then, most of the “deep” stuff is so naturally done -- it proves again that the "deep" stuff in “ behaviors” are simply data! – the soul of behaviors is data! the rest? Unnecessary complexity.



12. Back to CSLA. CSLA has strict regularities of its CRUD (DAOs) and services, therefore, you can say it conceptually splits them from entities, hence, I agree with you, CSLA is not "rich" -- give me a break, how can be a model be "rich" while so being constrained! However, not rich is not the problem though. It is the weirdness of those contrains that severely hurts the object model (always 4 CRUD methods, those "criteria" -- they are weird, aren't they!). Also, it has all those strongly typed collections – another antique OO feature.

13. However, I find ways to tear those things apart and use CSLA nicely.

14. OK, let's make it 14: In short, ADM is a good compromise.