cost of ro vs editable

jhw posted on Monday, April 23, 2007

What is the cost of instantiating an editable root object compared to a readonly object.

I have been using ro as child objects thinking that it would be less expensive. The result though is that my ro objects gets bloated with all the possible data rather than just what would be needed for a quick view in something like a list.

Is it standard practice to use editable child objects even if you will not need to edit them, only associate them with the parent by persisting their id in the parent objects db table.

Thanks

Heath

jhw replied on Monday, April 23, 2007

To answer my own questio:

I notice that I seem to be adding functionality into my readonly objects such as isValid and Fetch() that Rocky has not put into them. I'm thinking if it was so much cheaper to use ro child objects, he would already have that functioanality built in.

ajj3085 replied on Monday, April 23, 2007

Hi,

Well, i would think pretty much every Csla object will need code to fetch.  If your child cannot be edited, then I don't understand why you would even need an IsValid property.

What exactly is your use case?

jhw replied on Monday, April 23, 2007

I use an isvalid() just to see if it has been set from the db, rather than merely instantiated for databing . Eg: If I have a child city asso'd with a person, I want to instantiate the city for databing. But I don't want the person to be valid until the city is set.

jhw replied on Monday, April 23, 2007

All in all i think i will just use editable child objects from now on.

The thing i really wanted to know from my origiinal question wasn't the cost of loading the data, but the cost of instantiating editable objects with all the extra functions such as isvalid, isnew, checkrules, etc. That is the part i was not sure about. I just assumed there would be a considerable extra cost to that so I always used child ro objects, though in the end it has caused me extra work. Though I like my work, no extra work is wanted.

Thanks everyone

ajj3085 replied on Monday, April 23, 2007

It seems odd that you would have a city class, unless there's more than just a name there.  I would think it would be easier and make more sense to expose City as a string on the Person object, and simply have a rule that City is required.  Person could then use a Csla NVL to see if the city exists in the list already, and if it doesn't, add it to the city table itself (and ask the list to invalidate its cache, if any).  If the city does exist, you can simply set the id from the NVL.

HTH

Andy

 

jhw replied on Monday, April 23, 2007

Andy

This is getting to the point now. Often I have children where I only need to display a subset of their full data. So I would make a ro child as I need the user to set that child by selecting it from a list. If only all was as simple as having a string for a city.

But then  I find myself making multiple ro classes for different uses. And adding functionality for ensuring they have been set. In the end it creates a lot of extra work, so I am looking at just using full blown editable child objectes, with all their data, to save myself a lot of extra work. It is a trade of  between extra work and how the program will perform with the loading of editable objects rather than just a readonly object.

While I can understand the cost of loading data, I  don't  know enough to see the difference in cost of loading editable vs  ro objects, without considering the data aspect.

Heath

jhw replied on Monday, April 23, 2007

I agree with your point about just keeping the name string, as well as the id of the objects. It keeps things simple. If I use full blown children, the sprocs can get very bloated as you can end up with a whole chain of child objects as each has it's own.

Eg: If i have a child city, then i have to load a child province as well. In more complicated classes, this can get really complicated and bloated.

Earlier I had tried using the simple method you mentioned, but it seemed that I was missing the point of all Rocky's work so I went to child objects. I will try this simpler method again, as in hind sight, it did work better.

Heath

ajj3085 replied on Monday, April 23, 2007

If your use case doesn't require editing of children then perhaps your children should be root objects themselves.  If you need to display them while editing the item to which they apply, a readonly object should be fine for display purposes. 

Now if you are adding lots of properties because of other use cases, that may indicate that you should have seperate RO classes to display the relevent data in each use case.  That way you are only loading the data that you need for a particular use case, instead of loading all data when  you will only need a subset for each use case.

HTH

Andy