Extending CSLA

Michael Hildner posted on Sunday, September 17, 2006

Hi,

Are there any resources/guidelines for extending CSLA?

What I'd like to do is subclass the necessary CSLA classes, just in case I want to change something, in a way where I wouldn't have to modify the CSLA code itself. I'm not sure what classes should be subclassed should the need arise.

This is purely academic right now - a learning exercise. The only thing I've found the need to subclass so far is BusinessBase<T>, because I wanted to be able to call MarkClean() when creating a new object.

Thanks,

Mike

DansDreams replied on Monday, September 18, 2006

I hacked the crap out of the VB6 CSLA and came to really regret it six months down the road when I had some really cool enhancements but could no longer take advantage of Rocky's releases.

I am now leaving Rocky's CSLA as is and insterting a subclass between that and my BOs, as you describe.

RockfordLhotka replied on Monday, September 18, 2006

DansDreams:

I am now leaving Rocky's CSLA as is and insterting a subclass between that and my BOs, as you describe.

I absolutely recommend using the approach Dan describes. I left quite a number of methods as protected and/or virtual/Overridable specifically to enable this type of extensibility. If you find areas that aren't extensible, please make me aware of them, and if I agree that such extensibility makes sense I'll typically open the API to enable more scenarios.

There are only 7 base classes (in version 2.1, 6 in 2.0) from which you should create business objects. It is best to create your own assembly, with your own framework namespace, and subclass those base classes. Then, in your business assemblies, you can inherit from your base classes rather than the CSLA base classes.

Even if you don't alter any behavior initially, this is a good idea, as it gives you flexibility to change later on, without having to go change the base class for all your business classes.

Michael Hildner replied on Monday, September 18, 2006

Thanks for the replies. I'm doing this in 2.0.3. I assume the 6 base classes to subclass are:

BusinessBase<T>
BusinessListBase<T,C>
CommandBase
ReadOnlyBase<T>
ReadOnlyListBase<T,C>
NameValueListBase<K,V>

Which makes sense to me, but what about other classes, like BusinessPrincipalBase? Like I said earlier, I don't have a need to subclass all this right now, but if it's a good idea to give flexibility later on, should more stuff be subclassed?

Thanks,

Mike

RockfordLhotka replied on Monday, September 18, 2006

Normally you'd only have one custom principal class in your app - so creating a base class for that one class seems unnecessary. In general this is true for other CSLA classes as well, so the 6 you list should be sufficient.

If you follow a behavioral OO design approach, one of the steps you follow should be to assign "stereotypes" to each object. EditableRoot, EditableChild, etc.

If you end up with objects that don't fit one of the 11 CSLA stereotypes, you should look for commonality across those un-assigned objects to see if you have another stereotype within the context of your application. If so, you may want to create your own new base class - in which case you might inherit from Csla.Core classes to create hyrbids or new concepts to meet those needs.

Michael Hildner replied on Monday, September 18, 2006

Ok, cool, thanks. Makes sense. And thanks for answering the "why" - which I was alluding to in my first post when I said I wasn't sure which classes to subclass.

Regards,

Mike