How can collections of Business Objects be made more efficient in this senario...

pauldaly1982 posted on Thursday, July 20, 2006

I have a business object with many properties.  I want to bind a collection of that particular business object to a datagrid, but I only plan on displaying a few of the business object's properties on the datagrid.  (ex: master-detail forms where the details are only pulled upon selection from the concise master list).

I see the value in the maintainability of Business Objects, but I don't think it makes sense to load the collection with all of the data, when we know that a good portion of it will never be shown on the screen.

I could make another, "lighter" Business Object... that just contians the properties I need, but then I feel I'm loosing the maintainability benefits of Business Objects.

Is there something I'm missing?  How can this scenario be made more efficient in CSLA.NET

Thanks in advance for your help,

Paul Daly

Tom Cooley replied on Thursday, July 20, 2006

Paul,

The "lighter" business object is exaclty the way to go. In fact, you may want this to be a ReadOnlyList of ReadOnlyChild objects for display purpose, but when you select one from the list, you'll load the whole business object as an EditableRoot.

This is a common discussion here on the forums. Your Master-Detail should have a EditableRoot for the master with a ReadOnlyList of ReadOnlyChildren. Optionally, if you need to edit only the values displayed in the grid, then both the List and Child objects could be editable.

I completely understand where you coming from in the sense that your coding up some of this same stuff multiple times. But the mantra goes that "Objects are defined by their behavior, not by data" and duplicating a few properties in different business objects that have the same underlying database is trivial. I think this is the sort of thing that most people have a hard time accepting at first, but give it a try and you'll find that these truly are different business objects with different responsibilities.

Good luck,
Tom

pauldaly1982 replied on Thursday, July 20, 2006

Thank you for your advice Tom.

Just wanted to make sure I wasn't missing some feature of CSLA...

Thanks again,

Paul

vargasbo replied on Thursday, July 20, 2006

If your going to make changes to the object, then just keep it all in one. If it's read only, then write a "lighter" readonly object, but regardless of which one you uses, you should also look be looking to refactor you objects as biz needs change.

malloc1024 replied on Thursday, July 20, 2006

I am assuming you are editing the object with the datagrid.  If so, there are a few ways you can look at this.  Some will say this is a different use case and you should create a new class.  Others would say to you could lazy load the data you don’t need.  You could also take the easy way and forget about it.  If it doesn’t have a significant impact on performance, don’t worry about it.     If this is just a read-only list then you would use ReadOnlyList.

RockfordLhotka replied on Thursday, July 20, 2006

malloc1024:

Some will say this is a different use case and you should create a new class.

That'd be me   CSLA is very much designed to support responsibility/behavioral design of your objects. And that means designing objects for your use case, and only reusing them across use cases if they can be used without requiring change.

If you have created some sort of uber-object for a given data entity (say Product for instance), then you'll end up in trouble. While you may very well have a Product object with a property for every data value - it would almost certainly exist for the "Add/Edit a product" use case, and would not be well-suited to the "Get a list of products" use case.