Root Down CSLA Approach

chiefy81 posted on Wednesday, September 27, 2006

Hey gang,

Im getting up to speed with the CSLA framework and have a couple questions.  It seems like in CSLA you are always working in a sort of top down fashion. From a root object to its children and grandchildren maybe.  But typically data isnt in a heirarchy with a top level table(s).  To me its more of a web with everything interconnected.  For example say I have a root object employee and child collection of addresses.  while normally i may access the addresses from the employee object, wont there also be the situation where I have an address object and want to find its owner/parent/root (employee)?  I guess I am seeing the data as more of a web and it seems that CLSA is putting things in a heirarchy.  Maybe someone can understand the mindset Im in and help me understand CSLA better.

Thanks in advance

RockfordLhotka replied on Wednesday, September 27, 2006

I think the key shift in mindset is to avoid focusing on the data. To get a good object model, you need to focus first on the responsibilities and behaviors of your objects, and then plug in the data that the objects need to accomplish those responsibilities/behaviors.

The common hierarchical nature of the objects tends to flow from the most common use cases encountered when building business applications. Users really do typically start with an object and manipulate it, and other objects related to it.

This is not, of course, universally true - but it is the most common scenario, and so there's quite a lot of support in CSLA in this regard.

chiefy81 replied on Wednesday, September 27, 2006

Yes I remember that we should focus on the behavior when creating objects and data in the datamodel.

 Since this is the case, would it make sense to have in an object model, a set of objects like a root address object and then child employee object and also have a root employee and childcollection addresses in the same model?  Im not trying to solve a particular modeling issue with this example im just trying to see if this type repetition of data in different object types is acceptable (it gives me a bad taste because im used to thinking of data) if the behavior warrented the need for such a design?

Thanks again

RockfordLhotka replied on Wednesday, September 27, 2006

If you had use cases that required those objects, then yes.

The challenge with this behavioral approach, is that it is very difficult to discuss in the abstract. It is far too easy to come up with hypothetical scenarios that sound silly - and which are unlikely to occur in real life...

So yes, assuming you have some business use case where a business process starts with an address, and allows editing of employee data as part of that address (which sounds silly already - and so is probably not likely to be real), then you'd create objects with that relationship.

Also, if you have a business process that starts with an employee and allows editing of that employee's address(es) (which sounds more likely), then you'd create objects with that relationship.

JoeFallon1 replied on Wednesday, September 27, 2006

The Root, ChildCollection, Child structure you see in CSLA is most useful for those DB relationships which are 1 to many. This is the ideal case.

Where you might be getting confused is that there is nothing that limits you from having a Root BO that *contains* another BO - whether it is a child or a Read Only or a collection. These other BOs can be fetched separately (after the root is fetched.) They can also be in other root objects if needed.

You typically expose them to the UI as ReadOnly Properties.

This way the BOs can collaborate with each other.

For a given use case, I typically create a top level BO which contains many other BOs. But a given BO may have its own children and grandchildren. Others may not. The top level BO (Use Case Controller object) simply coordinates their activities.

Joe

 

 

chiefy81 replied on Sunday, October 01, 2006

Thanks for the feedback.  You mentioned that the other BOs can be fetched seperately or at the same time.  Most of what I have seen is that everything is fetched at the same time.  This seems to be the case because there are not many object to be fetched (at least in my examples, demos, projecttracker).  When using lazy loading, what would some good constructs be?  Lazy load bigger children? 

What about when loading grandchildren?  Is the convention to load the root to the grandchildren?  I realize that everything is dependent on the model, but I d like to get an idea of the norm at least and maybe some additional guidelines.

Thanks again

RockfordLhotka replied on Sunday, October 01, 2006

chiefy81:

When using lazy loading, what would some good constructs be?  Lazy load bigger children? 

Lazy loading is expensive, and should be avoided if possible. It requires a complete round-trip back through the servers to the database...

So the guideline (imo anyway) is less in terms of the size of the object, and rather in terms of its frequency of use. Lazy loading an object that is always used within your use case merely slows down your application overall. However, lazy loading an object that is rarely, but occassionally, used within your use case can have a net benefit over time. The reason being that usually the data never does get loaded and so you gain something.

If you always load the data, then lazy loading is always a performance loser - never a winner.

Except in one other case: background threading.

If you have a case where the data won't be needed right away, where the user won't care that the data isn't available yet (like it is on a background tab that they usually don't immediately click), then you might use lazy loading to get some data that you always retrieve - but to do it in the background.

Obviously this can give the perception of a performance increase (even though it is still expensive in reality). But you are also obviously increasing the complexity, and thus cost, of the development and maintenance of your application - and that should be part of your cost/benefit analysis as to whether the lazy loading makes sense.

In most cases, again imo, the cost of threading is higher than the benefit.

So while there are a few cases where lazy loading makes sense, they are really very rare - edge cases, where the extra cost to make it work is worth it due to the extreme benefit in that particular case.