CSLA.NET or other business object base class

The requirement that Lightspeed entities inherit from Entity<T> seems to preclude the use of other business object base classes, such as the popular CSLA.NET.  Has anyone developed a strategy to use Lightspeed as the data access layer for CSLA objects?

Hi Derek,

You're right that LightSpeed requires that you have an Entity<T> base class so that does mean you can't arbitrarily insert some other random base class. You can of course have a general base class that your entities inherit off as long as it, in turn, inherits of Entity<T>.

Out of interest, since you cite CSLA, what's the business object's functionality that you're missing? I haven't kept up to date with CSLA in recent years but my understanding was in the past it was great for databinding against and supporting all the various interfaces used by common components. LightSpeed provides fairly comprehensive support for most of these interfaces so if that's what you're after you may be pleasantly surprised. Having said that, if it's something else you're looking for I'd like to hear it as it might be something we could accommodate ourselves in future.

John-Daniel

Hi John-Daniel,

First, let me say that Lightspeed looks awesome.  We are still evaluating, but I think it's going to be a natural fit for us.  Thanks for your response.

My interest in CSLA has to do with our prior investment in it.  We have existing business objects that inherit from the CSLA base classes.  For those existing projects, we wish to change the data access to use Lightspeed or some other approach.  I had written my own attribute-based object mapping class (that I am aiming to get rid of) that I used as the base class for the CSLA classes, and in principle I could as you say use Entity<T> to replace my own class at the top of the CSLA hierarchy.  However I was hoping not to do that so that I can use CSLA "as is" and have less work to do each time new releases of CSLA come out. 

For new projects, we could use Lightspeed instead of CSLA, so long as Lightspeed has some of the functionality we need.  Some of the objectives of CSLA are listed below.  Some but not all are of interest to us, now or in the future.  I haven't yet looked at Lightspeed closely enough to know which it addresses.

1. Business rules and validation
2. Dirty tracking
3. Fine-grained authorization rules
4. Typed collections of child business objects
5. N-level undo
6. WPF and WinForms data binding
7. Multi-tier remoting objects

I'm not the poster child for CSLA, but there are some arguments against blurring the lines between the business object framework and the data access layer that you will have to weigh as you consider whether to take on more of that functionality in Lightspeed.

Thanks for your help.  I look forward to learning more about Lightspeed.

Derek

Hi Derek,

Thanks for reminding me of all the aspects of CSLA :-)

Generally with LightSpeed you'll get the following provided by Entity<T>:

• Business rules and validation
• Dirty tracking (2.x at the entity level, 3.0+ that will be released soon will support at the property level)
• Typed collection of children
• 1 level undo (when using the IEditableObject methods)
  
• WPF and WinForms data binding support
• DTO objects and support for WCF serialization of entities
  

So there's not too much that's missing - primarily N-level support for undo, authorization rules and more management around remoting objects.

Personally I'm not a huge fan of keeping a business layer and a data access layer separate. When using something like LightSpeed you'll tend to focus on a Domain Model approach - richer objects that you work with directly rather than layering things too much. This seems to work really well in practice but I appreciate there are arguments for everything in development and that you're not necessarily thinking the separation is the best approach either :-)

Keep me posted with how you get on and let me know if there is anything I can help you with,

John-Daniel Trask