Getting started with CSLA

Elizabeth posted on Friday, February 22, 2008

Hi all,

I'm new to CSLA, in fact this will be my first project using it.

Here is what I believe I need.

EditableRootObject "Configuration"

EditableRootObject "Drug"

EditableRootObject "Location"

EditableRootObject "Facility"

I also need list objects - EditableRootLists - . DrugList, LocationList and FacilityList

What I want to do is have the "Configuration" object be my main container object, I want it to contain or at least be able to access all the other objects through it. I'm not sure which CSLA base types I need to use to create my objects. I also don't really understand how to embed one object in another one (composite object), Is all I need to do is call the listObjects factory method and return the result?. Is there an example somewhere? Does my Drug object need to be an ChildObject in order for me to use it with DrugList? Or do I need 3 classes? An EditableRoot, EditableRootList and an EditableChild, such as this Drug, DrugList, DrugListChild ?

Is what I'm trying to do reasonable, as far as CSLA goes? In general?

Thanks in advance

RockfordLhotka replied on Friday, February 22, 2008

I recommend that you design your objects based on use cases, not data relationships. There are some excellent threads discussing object design on this forum, covering how to avoid using data-centric object design and instead to use responsibility-driven behavioral design.

You can use www.lhotka.net/search.aspx to look for them. Here's one though: http://forums.lhotka.net/forums/thread/18668.aspx.

Also, I'd recommend reading "Object Thinking" by David West (http://www.lhotka.net/weblog/WhatIGotOutOfObjectThinking.aspx).

What you propose with a single root object that contains all other objects won't work with CSLA - not unless you want to load much of your database into memory. CSLA is not designed for that data-centric approach.

Instead, you should look at the various tasks your users need to accomplish, their use cases. Design objects to meet the requirements of each use case, so the objects are small and focused on specific responsibilities.

JoeFallon1 replied on Saturday, February 23, 2008

It is hard to give you a specific answer without knowing more about your use cases. Some of what you propose is fine but you could also swap some of it with ReadOnlyLists and their self contained Info objects which are "lighter" and "faster".

One way to break down your use cases is to mock out the various screens of your UI. Then figure out what BO(s) are required to satisfy a given screen.

If you have a single gigantic screen then you may need a gigantic object that contains everything else.

But it is more likely you will have many screens that do different things.

e.g. Create a new Drug / Facility / Location (that's 3 screens!)

Edit the same things. Maybe on the same 3 screens.

etc.

As far as embedding one CSLA object within another it is very easy.

Private mOtherBO As OtherBO

Public ReadOnly Property TheOtherBO As OtherBO
Get
    If mOtherBO Is Nothing Then
      mOtherBO = OtherBO.GetOtherBO(someID)
    End If
    Return mOtherBO
  End Get
End Property

You typically expose the contained BO as a ReadOnly Property so that the UI can interact with it but not create a New instance of it and replace the one that you have provided.

Joe

meierk replied on Tuesday, February 26, 2008

As another CSLA (and C#) newbie I would like to share my latest learnings, which support what Rocky is saying about responsibility-driven behavior.

I just completed development of my first CSLA winform application that has two fairly large entry forms. The application is now in user acceptance testing and I am having to tweak the validation rules as they discover issues. Each form has several dozen data bound entry controls that share at least 75% common functionality and data. I thought it would be much easier to sustain if I create a single set of objects (5 in total) to support both forms. Big mistake.

Yesterday, as I was adding more validation rules, I quickly discovered that a user in one form could run into "invalid object" exceptions where the invalid data is not even visible in the form they are in. Remember, I said that the two forms were about 75% the same, but the other 25% is data that is visible on one form, but not the other.

Today I will be refactoring my objects into two separate sets. One to support the use case for the first form and the second....

I should also mention that as I neared the end of the development cycle, I started refactoring extensively by moving a large amounts of code from the client to the objects. Although this dramatically reduced the amount of source in the client, I now have to be very careful when I modify my objects. Of course, effective unit testing would reduce the risks of breaking things, but I haven't found a way to unit test without hitting the database yet (lots of mock discussion here, just search) so I haven't created any yet. No excuse, but that is now my reality.

I just hope my pain can help others.

Kevin

webjedi replied on Tuesday, February 26, 2008

I'm just getting into mocking the database...it's really interesting. If I can pass on a couple links:

http://aspalliance.com/1400_Beginning_to_Mock_with_Rhino_Mocks_and_MbUnit__Part_1.all

http://aspalliance.com/1456_Beginning_to_Mock_with_Rhino_Mocks_and_MbUnit__Part_2

I've tried this in one place (non CSLA project), in one particular unit test and so far I like the concept.

I am starting a new project where I am considering doing this for the whole thing (green field app). If I find anything interesting I'll write it up.

Elizabeth replied on Tuesday, February 26, 2008

Thanks Kevin, Ryan for sharing.

I think part of my problem may have been codegen tools. Actually mostly my mind set.

The tools seem to be very data centric, specify a table and bam, all your CSLA code!! No typing. I thought this was the greatest thing since sliced bread. Now, I'm not so sure. OOAD, Rocky and JOE tell me to design from my uses cases, but codegen was so appealing, I so wanted that to work. Oh well.

webjedi replied on Tuesday, February 26, 2008

Check out Codebreeze or my languishing project on Codeplex.

Codebreeze is definately more feature rich, but both will let you step away from the database when it comes to designing your objects. Codebreeze will use your database as a starting point to which you can then go in and reshape your objects to your needs. Mine starts by making you define all your properties (doesn't use a database at all) and then it just generates basic code from there. (Based on ProjectTracker).

I have 3.5 version in the works but it's slow going (lot's of irons in the fire at the moment).

RockfordLhotka replied on Tuesday, February 26, 2008

You know, the thing is they aren’t always mutually exclusive.

If you look at a typical app, a large percentage of forms are admin/maintenance forms. Each one tends to have a one-form-to-one-table relationship, though often with some NVL objects for validation. Each of these admin forms typically represents a very simple add/edit use case, and one where you really can use a data-driven code-gen tool to create the objects (and maybe even the UI).

Then a typical app also has a smaller number of complex forms where the real work happens, and where the users spend the bulk of their time. It is rare that these forms have any sort of 1:1 relationship with tables, and your objects should reflect the use case, not the data. But these forms are usually in a minority, and are the “interesting” ones anyway, so it is where you want to spend your design time to get everything right.

So personally I think the data-centric code-gen tools are great – you just have to realize they apply to just a part of your app (though often a large part – and the boring part).

Rocky

From: Elizabeth [mailto:cslanet@lhotka.net]
Sent: Tuesday, February 26, 2008 2:33 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Getting started with CSLA

Thanks Kevin, Ryan for sharing.

I think part of my problem may have been codegen tools. Actually mostly my mind set.

JoeFallon1 replied on Wednesday, February 27, 2008

I agree with Rocky.

(How many times has *that* been said on this forum?)

I use Codesmith to generate base classes for my BOs from my DB tables. And then I write code in a derived class to enhance the BO for my use case. The "boring part" is done in a few seconds and the "interesting part" is much simpler to handle.

Joe