Subclassing CSLA Base Classes - Best Practice?

Subclassing CSLA Base Classes - Best Practice?

Old forum URL: forums.lhotka.net/forums/t/7022.aspx

Tom_W posted on Saturday, May 30, 2009

Hi All

I think I may have got myself confused... I know that it's best practice to put a buffer between CSLA and your own code by inheriting the CSLA base classes (to create a YourCSLABaseClass) and then inheriting from these custom versions of the base classes for your actual application classes.

What I'm confused about is should your custom base classes be:
  1. Straight subclasses of the CSLA base classes, e.g. YourBusinessBase...
  2. ..or subclasses that correspond to CSLA stereotypes, e.g. YourEditableRoot
Either of the above would still inherit from BusinessBase, I'm just ensure which is the 'right' way to go?

One more related question; there seem to be a lot of posts about issues with generics and inheritance, do I run into these issues by taking either of the approaches above, or does that come if you inherit from your 'concrete' classes (i.e. if you inherit from say a concrete 'Contact' class)?


Marjon1 replied on Saturday, May 30, 2009

Hey Tom,

The approach that we have taken, and what I believe is the recommended approach is to subclass based on the standard CSLA stereotypes. Of course, you may specialize even further down the path, but if you want to add a standard method or behavior to all editable root objects it makes it a-lot easier to do. We have several read-only classes / lists, but they all work of our standard base objects. These all have specific behaviors for what the object does and the read-only subclass really does not but inherit from CSLA.

We haven't made the move to 3.6.x yet, so can't really comment on the inheritance issues. But I believe that they come from having more complex scenarios, such as having a generic based contact class. Having a specialized class that uses the same generics as base CSLA objects shouldn't cause any problems that wouldn't when using CSLA normally.

Tom_W replied on Monday, June 01, 2009

Thanks Marjon and Rocky.

Marjon, do you find there are methods that belong in YourEditableRoot say that don't belong in YourEditableChild?  I.e. do you find there's value in stereotype based base classes rather than primary clsa object based base classes?

JoeFallon1 replied on Monday, June 01, 2009

Nope.
I have the ones Rocky listed (plus ERLB).
No need (for me) to distinguish between Root and Child.

Joe

ritchied replied on Thursday, October 08, 2009

1) Is there some sample code for creating abstract subclasses for each of the primary base classes?

2) Help with subclassing NameValueBase.

I created my base "look up" class from NameValueBase and a useable decendant class "province look up".  My base class contains all the code to read my standard look up tables based on a dynamic string value. (the value is used match the table and column names).  My problem is I can't figure out how to set it in the decendant class.

I can't figure out what method to override to initilize my dynamic string value.

Sample code that does NOT work:

public class LookUpBase : NameValueListBase<int, string>
{
        protected string dbName = "";  // must be set by decendant class
    ...implementation code which uses dbName to build SQL...
}


 public class ProvinceLookUp : LookUpBase
 {
    
        protected override void Initialize()
        {

         // this method never gets called
           dbName = "PROV";

           base.Initialize();
        }
 }

JonnyBee replied on Thursday, October 08, 2009

Hi all,

Take a look at the MyCsla project - this shows how to make your own subclasses (and may be used directly into your own application). You can download it from CslaContrib and it is also included in the ProjectTracker sample project for Csla 3.7.1 for N2.

ritchied replied on Thursday, October 08, 2009

JonnyBee,
The MyCsla project and the other stuff in CslaContrib is awesome! Thanks for sharing.

lazaroms replied on Thursday, July 08, 2010

Where can I find the MyCSLA project for CSLA 3.6?

RockfordLhotka replied on Sunday, May 31, 2009

I generally recommend creating an abstract subclass for each of the primary base classes.

Even if your subclasses are empty, they still provide an extensibility point for the future.

And since all you are doing is mirroring the existing base classes, your business object code is unaffected, other than choosing to inherit from your base class instead of the CSLA base class.

Tom_W replied on Sunday, May 31, 2009

Hi Both

Many thanks for the responses.  Rocky, are there any obvious gotchas in creating stereotype base classes (YourEditableRoot etc.) as opposed to primary base classes (YourBusinessBase)?  It seems like there might be some value in separating out the different stereotypes... although I must admit I can't think exactly what yet.

In fact, would a hybrid of both of the above be sensible, i.e. YourConcreteClass inherits from YourStereotypeBase inherits from YourBusinessBase inherits from CSLA.BusinessBase?  Again, are there any obvious gotchas in this approach... and am I just making life unneccessarily complicated?

I figure that the hybrid approach might allow the best encapsulation of appropriate functionality at each level?

RockfordLhotka replied on Sunday, May 31, 2009

I think there used to be some value in having different base classes for ER and EC. But with the child data portal concept in 3.5 and higher I don’t think there’s any value in the separation anymore.

 

Rocky

Copyright (c) Marimer LLC