Is it Root, Parent or Child?

ppcuban posted on Monday, November 13, 2006

I have an object inheriting from BusinessBase. We are having a hard time trying to determine if we should MarkAsChild the object since it can be directly retrieved or updated via the dataportal (Root) and it's gonna be contained by another business object (child) as well.

I bought the book c# 2005 business object and i honestly find it really confusing. The sample project ProjectTracker is very specific to that situation and doesn't expose all the possible combinations. I am a 8 years experienced oop programmer and truly i am having a hard time with Csla. is there any tutorial about Csla.

I really need to get to understand this framework since my boss is sticked with it and there is nothing i can do about it.

Thanks in advance!!!

Rocky!!! Save Me!!!!

ajj3085 replied on Monday, November 13, 2006

Hi,

First, take a look at your design.  What you're describing is a switchable object, which usually indicates a problem with your design.  Its rare that a business object can be both a child (only updated withing the scope of its parent) and a parent (updated by itself).  You probably should have two different objects.

Many people have problems because they are focused on designing objects around data, where Csla you design your objects around behavior.  The behavior the objects describe are there to fulfill one use case.  If one object can fulfil two use cases, that's ok, but it the behavior must be identical between both use cases.  This is rare as well.

The Project Tracker sample is very specific, you're right.  That's how you're supposed to design your objects.. directly from your use cases. 

So look at your use case, design your objects around what needs to be done in the use case.  Move on to your next one.  Create all new objects to fulfill that case.  Repeat until you have implemented all use cases.  Only then should you look at sharing objects between use cases, and only if the object fulfills the exact same behavior in both cases.

Try going slower through the book; this is something all of us have problems we.  We're used to thinking in terms of normalizing data, and focusing on code reuse.  As Rocky has said here before, we to focus on the use case and the behavior it describes.  Code reuse can be a nice side benefit, but is not our goal.

HTH
Andy

ppcuban replied on Monday, November 13, 2006

Ok. I am going to be more specific.

I have a User object that inherits from BusinessBase<User>. We want to try to use all the functionalities of Csla with this object so we can use it for our whole new system we are trying to create now.

My doubts started when we wanted create a Users list inheriting from BusinnesListBase. Should User be a Child() of Users neccesarily or not? We need the collection of User for sure but at the same time we want to be able to edit directly the object User without using a parent collection. It makes sense so far? If I mark User as Child then i won't be able to directly update or make changes to the object due to the restriction applied when an object is Child.

Any idea about this?

Thanks

RockfordLhotka replied on Monday, November 13, 2006

ppcuban:

My doubts started when we wanted create a Users list inheriting from BusinnesListBase. Should User be a Child() of Users neccesarily or not? We need the collection of User for sure but at the same time we want to be able to edit directly the object User without using a parent collection. It makes sense so far? If I mark User as Child then i won't be able to directly update or make changes to the object due to the restriction applied when an object is Child.

The problem you are facing is that you are focusing on the data, not on your use cases.

You are describing two different use cases, one where you are editing a single user, and one where you are retrieving a collection of users (presumably not for editing).

In Chapter 6 I try to lay out the design process you should follow for your objects - focusing not on data, but on the behavior and relationships between objects.

If "User" has the responsibiilty of "Editing data about a user" then it shouldn't be used in a collection to display data - it should only be used for editing data.

So if you also need to display a list of users, then you'd build a ReadOnlyListBase-derived list, with ReadOnlyBase-derived child objects, possibly called UserList and UserInfo.

Now if you, for some odd reason, have two use cases where you are allowing editing of user data (which would be odd, but users come up with wierd stuff...), then you have a tougher challenge. But that's always the case with strange requirements...

In CSLA .NET 2.1 there's a new base class: EditableRootListBase. This class exists so you can retrieve a collection of root objects, bind that collection to a grid, and allow the user to edit those root objects. The ERLB class takes care of immediately calling Save() on each root object as the user leaves the row, so any insert/update/delete actions are immediate.

ERLB may or may not be what you are after, but it helps in some cases.

If you need single-object editing AND deferred collection editing, then you might be back at using a switchable object. As Andy points out, this usually indicates a flawed object model - but it could indicate wierd user requirements too...

ppcuban replied on Monday, November 13, 2006

So, practically i have to create 2 similars objects? I am looking at the ProjectTracker and Resource and ResourceInfo have the same fields almost. It seems to me a little odd because i already have an object that i could use no matter the use case, BUT if this the way it should be done in Csla, then i will create them. Maybe there is my problem. I think that one User class is enough for everything about it.

So, in order to get this. If i have a scenario where i am going to edit by itself an object, then it's BusinessBase BUT if the same object is going to be used as an item in a collection, i should create an object similar inheriting from ReadOnlyBase with the fields i want to show in that collection.

Now, it seems interesting that EditableRootListBase, i am gonna try it. By the way, Congratulations, great work. I just find it confusing the whole framework but i guess i need more time dealing with it until i feel comfortable.

Michael Hildner replied on Monday, November 13, 2006

Yes, you'd create two similar objects. Although they're similar only in that they share some of the same data. They don't share the same behaviour, so you need multiple objects.

I started with CSLA a few months ago, and was incredibly confused by the very same thing. Especially because previously I was using a business object framework where there was only one bo for everything you needed to do (although some folks around here might say that wasn't a real bo framework).

My thinking was why would I need two different object when they share the same data? Aren't I duplictating code? In a way you are, but it's much easier to maintain if a bo doesn't have multiple reasons to change. So you're going to end up with a lot more objects than you first thought.

Mike

ppcuban replied on Monday, November 13, 2006

Where can I download the 2.1 version? can't find it in the website.

ppcuban replied on Monday, November 13, 2006

I FOUND IT. Thanks.

ajj3085 replied on Monday, November 13, 2006

ppcuban:

So, practically i have to create 2 similars objects? I am looking at the ProjectTracker and Resource and ResourceInfo have the same fields almost. It seems to me a little odd because i already have an object that i could use no matter the use case, BUT if this the way it should be done in Csla, then i will create them. Maybe there is my problem. I think that one User class is enough for everything about it.

We all struggled with that.  Its because you're thinking in terms of data and / or code reuse, which really isn't the idea behind OO, which is modeling behavior. 

Don't worry about many classes; each one should exist to fulfill a use case in your system.  It should do that (or help do that, as some use cases will need more than one object) and do that well. 

ppcuban replied on Monday, November 13, 2006

Since i am new to the Csla Framework, should i use the 2.o version or go straight to the 2.1?

I have the book, so, my common sense tells me to stick with the version of the book. What do you suggest to me?

 

thanks in advance.

Jose

ajj3085 replied on Monday, November 13, 2006

Go with 2.1; there are enough new and compelling features.  Most of the framework is the same as covered in the book.  The one big difference that sticks out for me is type level authorization and validation rules, which can yield pretty substancial memory gains, among other things.

Also, Rocky will soon have a 2.1 ebook out, which will be a supplement to the paper book and just cover the changes.  I think its due out soon.

Michael Hildner replied on Monday, November 13, 2006

Funny, I was going to recommend staying with the version that matches the book. I think that Andy's right that there are enough new and compelling features in 2.1, but I fear the frustration of not having an explanation of the new stuff.

Just that I think if you're brand new to CSLA, there enough stuff to learn without getting confused by things that aren't documented.

Also note that there's a bunch of errata in the book - there's a link to the errata for both VB and C# from Rocky's home page. I printed it out, attached it to my book, and marked the relevant pages so I wouldn't miss anything.

ppcuban replied on Monday, November 13, 2006

Well, i will stick with the current version of the book but i will look at the other. I am gonna read the book page by page calmly. You are right, i skipped a lot of chapter just looking what i thought was most important but obviously, that was my down fall.

I appreciate all the time you dedicated to me about this topic.

Thanks you all.

ppcuban replied on Tuesday, November 14, 2006

For what i understood from chapter 6, Use Cases can be translated as a Form view?

 

For example, one form for updating the user is an use case, one for viewing all the user is another use case... am i right?

it makes sense then to design classes for each form SINCE i think we only need to create one form and reuse it everytime we need that use case. am i right?

Good morning... by the way

ajj3085 replied on Tuesday, November 14, 2006

Good morning.

Not quite.  See, you don't want to model you business objects after UI requirements.  So true requirements won't include any specification at all on the UI.  The use case simply will say 'user edits a project,' or in your case, a user.

So you have a use case for updating a user, a use case for viewing user data, and neither of those should mention the UI at all.

Does that make sense?

Andy

ppcuban replied on Friday, November 17, 2006

Good morning.

Ok. i have a new problem now about the same thing. We have end-of-the-day processing. We have to go through every record in a database and make some changes to some fields. We are talking about 1 million records or more. My plan is to load chunks of those records in a collection, modify them depend on the criteria, and submit it back to the database server.. Ok.

This is what i think. Create a BLB class wich is the collection and another new class ( i already have User, UserInfo) let's call it... UserX wich inherits from BB and make it Child() of the collection so i can update it from the collection. Is that OK?

I wonder how many classes i will need for a system with an almost 300 tables database...

 

RockfordLhotka replied on Friday, November 17, 2006

I recommend using the concept of "stereotypes" in your object design. A stereotype is a description of common behaviors your objects require to do their job.

The CSLA base classes support around a dozen stereotypes that should help guide you on which to use. BusinessBase supports the "Editable root" and "Editable child" stereotypes, BLB the "Editable root list" and "Editable child list" stereotypes, etc.

For batch processing, the reality is that BB and BLB offer a whole lot of features you don't want or need. They exist, in large part, to support some UI concepts like data binding, n-level undo and so forth. The authorization support is probably not too useful for batch processing either.

Of course they also support validation, which you may want to leverage.

The thing is, BB and BLB can be used to implement other stereotypes as well - but the coding structure of your business classes would differ from the standard Editable stereotypes. What you need is a "Batch item" stereotype, with a "Batch root list" stereotype.

The collection structure wouldn't vary much. But your child objects - the Batch items - would have a different structure from a typical editable child.

Specifically, I wouldn't put calls to CanReadProperty, CanWriteProperty or PropertyHasChanged in your property code. In the property set block I'd call MarkDirty directly, thus bypassing the validation rules and data binding concepts - because they aren't needed there in a batch mode.

Then I'd explicitly call ValidationRules.CheckRules() just before the object is saved. You might consider creating a Validate() method on your batch objects (and your collection) so you can call myCollection.Validate() to trigger all the rule checking on your whole batch. Then you can decide whether you can save that batch, or the individual items in that batch.

What I'm getting at is that the Editable root/child stereotype is designed to support interactive UI scenarios. It is not efficient for a batch scenario, because in a batch scenario you typically don't need to check authorization on every property, and you can often just load the object and then check all its rules once right before commiting the data.

But perhaps more importantly, I recommend implementing batch processing using stored procedures if at all possible. The overhead of moving all your data out of the db, processing it and putting the data back into the db is pretty high. If you can do the work directly in the db you'll get much better overall performance in most cases.

ppcuban replied on Friday, November 17, 2006

When you mention "stereotypes" you actually mean Interface and derived classes? So, the combination of those abstract class and Interfaces would create a stereotype?

We know there is a Consulting company close to our area Duluth. We would like them to mentor us about the whole csla framework. Could you give us directions on how to contact them.

 

RockfordLhotka replied on Friday, November 17, 2006

---

From: ppcuban [mailto:cslanet@lhotka.net]
Sent: Friday, November 17, 2006 10:13 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Is it Root, Parent or Child?

When you mention "stereotypes" you actually mean Interface and derived classes? So, the combination of those abstract class and Interfaces would create a stereotype?

We know there is a Consulting company close to our area Duluth. We would like them to mentor us about the whole csla framework. Could you give us directions on how to contact them.

 

ajj3085 replied on Monday, November 13, 2006

Ok, then you need to ask yourself this:

What do you need a list of users for?  Probably just display I'm assuming.  So you'd have a ReadOnlyListBase (Users) and a ReadOnlyBase (UserInfo) to fulfill this requirement, including authorization rules on who may view the data at all.

Then you probably only edit one user at a time (which is a seperate use case, I would guess).  This would be a User object, which subclasses BusinessBase.  It has all the knowledge on how to edit a user, including authorization rules.

Do you ever load a list of users and edit them in one shot?  Not likely.  If you do, each change to a user is likely independant to changes to another user.  In this case, you may want to check out EditableRootList and subclass that.

Does that help you at all?  The more information on your use case you give, the more specific suggestions we can give.

Andy

JoeFallon1 replied on Monday, November 13, 2006

I usually think in terms of Root and Child BOs.

Simple definitions:

Root = BO that can be retrieved and saved to the DB on its own.

Child = BO that is contained by a Root BO (or Collection) and can not be retrieved or saved directly to the DB.

Parent = Any BO that contains other BOs.

e.g. The Root BO is the Parent of the contained collection which is the Parent of the the contained child BOs.

 

ppcuban replied on Monday, November 13, 2006

Expert c# 2005 Business Objects / page 120.