Csla and 'non-data' objects

Crestline posted on Monday, April 16, 2007

Hi,

Sorry if this question has a rather simple answer but I'd like to get an idea of what others are doing...

We've been using Csla for a while now and love it.  The more we use it, the more we appreciate it.  So far we have been using it for very data application specific purposes but I was wondering how Csla would fit into sittuations where we don't really need to be connected to a database?  Would you just simply remove the data access portion of the objects and continue on as normal?  Create your own object from scratch as we would have in the past and not use Csla?

Anyways, looking for some ideas.

skagen00 replied on Monday, April 16, 2007

I can't think of too many applications that wouldn't require some sort of data access - that is, some "hydration capability of a business object from a storage medium".

But there's nothing that says you need to provide an implementation for the fetching, data-access & "Get" factory method of an object. Or, that the hydration of an object need necessarily come from a database - it could be a text file, Web service, or some other means.

What exactly do you have in mind?

Crestline replied on Monday, April 16, 2007

Well, I don't really have a specific example at the moment but it just seems like once you start hooking up the Csla objects to the UI, I seem to always end up creating other classes here and there.  This more than likely caused by a bad design on my part but there just seems to be times where the only solution is to create something new rather than, say, extend one of the Csla objects.  I guess I'm more looking to see how other people are dealing with this sort of thing, if they are, and maybe take advantage of someones experiences.  I'm fairly new to .Net programming, only a few years of daily work, but I sometimes question if I'm missing some of the basics now and again...

Bayu replied on Wednesday, April 18, 2007

Hey,

I think I understand your question, but I am not sure.

At all times you should realize that all functionality that is provided by Csla is optional. At its core it is simply about objects with properties and logic, just like any other 'business object'. The great thing is that when you define your properties and logic (i.e. methods/behaviors) on Csla-based objects, you get a lot of frequently sought after functionality for free, like persistency, databindability, authorization and validation. Yet, all these remain optional extra's

It is perfectly fine to not make use of all these features in all of your objects. As long as you use some of them in most of your objects you still have a valid case for using Csla. If however, your hardly make use of any feature in most of your objects you should rethink your choice for Csla.

Bayu

david.wendelken replied on Wednesday, April 18, 2007

We've used Csla classes to handle lists of users that were populated via ActiveDirectory calls. 

We still used the same data access methods, they just connected to ActiveDirectory instead of a relational database.

I've also used NVList classes for hard-coded lists of choices.

chrisc1234 replied on Wednesday, April 18, 2007

I would think the main question would be "Is it a business object?", not where the data comes from (be it a relational database, a web service, hard-coded,  XML file, Active Directory, etc.).   I would not use CSLA for a class library, but if it performs business logic/validation related to the specific application, then you probably want to use CSLA classes for the object(unless it is just "Helper" methods).  Or if you need the data structure, such as a NameValueList or other functionality (security, binding, etc....but then those really are directly related to business logic).

On my current project (my first CSLA project), I even have a ReadOnly Business CSLA class that uses a DataSet.  I needed a DataSet for a lookup table (not exposed outside the class), so I loaded the data into a DataSet (something not normally done with CSLA) since it was the easiest data structure.  I find the CSLA classes very flexible and with a little ingenuity, you can do a lot.  I have implemented caching using the MS App Block, have abstracted the data layer, and have used inheritance (I have abstract business classes that inherit from the CSLA classes that I then derive my concrete business classes from).

RockfordLhotka replied on Wednesday, April 18, 2007

I do this all the time - at least for demos and testing. If all I want is an object that supports data binding with some validation and/or authorization, then a BusinessBase object with no data access works great!

But the thing is, you should use CSLA base classes because you want some feature(s) provided by the framework. Like data binding support or validation, for example. If you want those features, but not data access, then that's fine - go for it.

But if you just want an object to hold some data and don't need any CSLA features, then there's no sense inheriting from a CSLA base class.

Crestline replied on Thursday, April 19, 2007

Thanks for all the feedback/suggestions.  I guess I wasn't to far off track. 

'Helper' metheds were mentioned above and that's pretty much what I was refering to.   We end up creating a few 'helper' objects/classes here and there, was just wondering how others are handling things like that and it looks as though it's about the same way.

Thanks again.