CRC - Concept

white911 posted on Friday, October 27, 2006

I need to get clear with some CRC design concepts. I just came back from the VSLive conference in Boston where I heard Rocky explaining his new approach with using CRC, and the main idea was that each object can only have one responsibility. However an object may have one or more behaviors to accomplish his responsibility. Example: A Customer Object responsibility is to "Enter Valid Customer Data", and it may have behaviors to collaborate it.

So what I am not clear is, why a customer object would have the option to fetch itself from the database passing an ID parameter, isn't this another responsibility like "Fetch Customer Data"? This is not connected at all and it's not part of the behavior of the previous responsibility to "Enter Valid Customer Data"?

I know I have it wrong, but I want to understand the idea.

Thanks

 

malloc1024 replied on Friday, October 27, 2006

I don’t believe you have it wrong.  A responsibility is a reason to change.  When you add persistence logic to a business class, it gets another reason to change.  CSLA business objects do violate the Single-Responsibility Principle.  This is why some people create a DAL.

hurcane replied on Friday, October 27, 2006

This is an area where two reasonable people can disagree. You could argue that the responsibility of editing includes fetching and saving the data. The business object includes the data, so I would argue that you can't remove that responsibility from the behavior.

Now, the practical question is how does the editable object save its data? Does it do it directly (as presented in Rocky's book), or does it collaborate with another object that is part of a DAL? This is an implementation detail that does not affect the overall responsibilities of the editable business object, as viewed from the perspective of the client using the editable business object.

I'm working on a project where I am implementing both scenarios. Most editable objects contain database-specific code to fetch and save their data. However, I have an Address object that has to support multiple data sources because the database design has highly de-normalized address data. The Address object collaborates with another object that handles the database details.

Either way, the data-access behavior encapsulates and hides the data acces details from the user of the editable object. Now, if you want to argue that the client should be responsible for creating the DAL object and passing to the editable object, that would be "wrong". :-)
 

malloc1024 replied on Friday, October 27, 2006

IMO, when you add persistence logic to a business object, you do add another responsibly to that object.    The business class now has two reason to change, when the business rules change and when the persistence logic changes.  I do realize that the single-responsibility principle is only a guideline and compromises must be made when developing software.  I am not saying one way is correct and the other isn’t.  Rocky does provide good reasons on why he placed the persistence logic in his business classes.  However, I do believe that it does violate the single-responsibility principle.

ajj3085 replied on Friday, October 27, 2006

I agree; the book pretty much explains this decision.

In all honestly though, and object has to load from somewhere though.. whether another object or using Ado.net directly. 

You can also mitigate this as well by creating helper classes.  For example, your fetch could be something like this (psuedo code):

private void DataPortal_Fetch( ) {
     Producthelper.LoadInstance( this, 5 ); // loads the instance with data from product id = 5
}

But you usually need a new property anyway, so you'll still have to modify the object.