Business object inheritance - Another question

simon_may posted on Thursday, September 28, 2006

I have recently read a number of threads in this fourm dealing with aspects of business logic design using CSLA business objects. Some really usful dicussions. The most recent one of note was posted by Tom Cole of Magenic entitled "Try a collaborative solution before inheriting your CSLA Business Object".

I accept that inheritance has its problems and should be used carefully, that objects should be designed based on behavioural requirement and that compostion, aggragation and the techniques discussesd by Tom et al all provide design options, that circumvnet the need to use inheritance

I would however suggest that inheritance does have its place offering a way of delivering reuable funtionality accross a closely related set of classes without the need for design gymnastics or code 'cut and paste'.

CSLA 2.x introduced generic base classes for the business objects and the use of genrics in the collection classes has delivered significant benefit. However the BusinessBase<T> and readonly equivilent deliver minor benefits but inhibit (or at the very least make very difficult to acheive) business object inheritance.

The question I pose to those with far more experience than I, is this. Do the benefits of a generic BusinessBase class outweigh the design flexitbility provided by judicious use of inheritance in the business logic classes design?

I cant help feeling that pragmatism if falling prey to purity of disign.

Simon

skagen00 replied on Thursday, September 28, 2006

Hi Simon, your statement is something I've really wondered about myself - and Rocky had mentioned in one post that the reason for Core.BusinessBase to still exist (forgive me if I'm misquoting you Rocky) is to allow classes to inherit from Core.BusinessBase instead to help alleviate the difficulties of inheritance. (I'm going to go back and find that post and add a link).

I know I've been really working to ensure that I stick with BusinessBase<T> so that I'm honest with the most common use of the framework, but there are undoubtedly places where I find myself saying - damn, I can't do that - generics.

Edit: here is that link: http://forums.lhotka.net/forums/thread/2758.aspx

RockfordLhotka replied on Thursday, September 28, 2006

I certainly had concerns about generics from day one, which is exactly why Core.BusinessBase still exists.

In a very early version of 2.0 I actually had two top-level base classes: BusinessBase and BusinessBase<T>. I ended up removing the non-generic version as a top-level base class to keep the framework simpler and more clean - but I kept the non-generic base class behind the scenes because generics really do complicate things in some cases.

That said, I think interfaces help quite a lot. Since 2.0, I've been steadily (though cautiously) adding and expanding various interfaces to enable polymorphic behaviors for people using the generic base classes.

Finding the right balance between pragmatic productivity, and purity of design is always a challenge...

simon_may replied on Thursday, September 28, 2006

Rocky, Yes the new interfaces introduced in 2.x are very useful. I am only interested in inheriting business funstionality rather than technical functions (your new interfaces fit in to this catagory).

My previous post crossed yours and explains a little where I intend to go.

BTW: the point about pragmatism and purity was not a dig at you; more a sense of frustration with the fact that life doesn't provide a nicely packaged set of perfect answers.

Simon

simon_may replied on Thursday, September 28, 2006

skagen00, In fact that thread answers my question perfectly (thanks for finding it). In post 2852 Rocky has anticipated my/our delema.To my mind and because of the way I have chosen to develop my apps (heavily model based code generated) I will provide myself with a non gnenric replacement for BusinessBase<T>.

I, like you, do not wish to deviate form the framework but in this casse the designer has anticipated the need and though for excellent reasons has not extended it himself understands the need, and will hopefully bear this in mind for the future.

You may not want to commit Rocky but perhaps you want to comment.

Simon