I've been doing a lot of reading about Business and Data Logic over the past week. I have a question regarding preformance and scalaiblity.

We deal with complex business objects in our suite of products.  My question is what is the best way of storing a "collection" of these business objects.

Ex:

A User is an actual object with CRUD and massive backend to manage security, permissions, and other functions.

If we need to display a list of users, we will run a stored procedure that returns a lsit of users and we'll bind that to a DataTable (i'm not a big fan of DataSets for 1 table). Then we bind that DataTable to a Grid for display.

Now, if we need to instantiate a User we'll create a new User with the ID from the DataTable.

Is that efficient?

I've started playing around with Generics using List<T> for holding complex objects read in from our XML settings files, which works really well. I'm wondering if that should be used for holding a list of objects rather than a DataTable of results.

Thanks,

The answer depends on what you need to do with your "List" of data. Are you simply binding to a GridView? or do you need to do some logic on the instances of the List?

Using a Generic List<MyUserObject> is probably what you want to do (as you mentioned that you would be building an instance of the "User" from the datatable anway).

Having the DataTable might be pointless alltogether for what you are doing... could you explain a little more on what is done with the List of Users?

I don't know if this is what he is doing, but it did bring to light a question I've been struggling with.  Let's say your gridview has 4 columns.  The first two columns are from your user object, no problem.  But the next two columns are data related to the user object by the user id, that you must look up.

The easy approach is to call a function for each row.  But a more sensible approach might be to preload them all when you load the users, and somehow match them up.  But the most ideal might be to somehow "join" them together.  Right now our developers do this with datatables, because it simply is not something I have figured out how to do easily otherwise.

Do most ORM frameworks have such a concept of a join of two collections that can be bound as a single collection to a gridview?

Thanks for the replies.

After re-reading what I posted I came to my own conclussion on what would be better. DataTables/DataSets are best used when used for, well tabular display. Sure they can be used as a Business Object to be passed through teirs, but complex objects are better for that, in our case.

A List<T> of objects is useful to avoid subsequent lookups.

TAsSunder, what we've done in cases like that is have collections as properties (set to null) until accessed. If you wanted to grab the history of the user, which is a List of all history. It is not populated until you ask for that history, and then returns the List.

The example in question was this:

Return a list of users. Each of those users will have a collection of data:
-History
-Roles
-Departments the user is a part of
-Email lists the user is a part of.

Instead of having a DataTable as each of those seperate collections,  Would it have been better to have List<t>'s of Complex business objects for each one? The conclussion I came up with is that it depends on how I want to render the  to the user.

For roles, the user only gets a list of roles with a lot of Front end JavaScript to support adding and removing with ease. A List<t> is better for that.

For History, which does not need to support full CRUD, only Create and Retrieve, it's better as a standard DataTable.

 

I use the following to help connect the business objects to controls such as the ObjectDataSource:

[

DataObject(true)]
public class CSampleList
{

private List<CSample> _data;

[

DataObjectMethod(DataObjectMethodType.Select)]
public List<CSample> GetExample(string SampleParameter){

return _data.Find..... (ie. use predicate search)

}

Then I have my entity/value class - no methods

public class CSample

{getters, setters

}

 

 

RTernier:

TAsSunder, what we've done in cases like that is have collections as properties (set to null) until accessed. If you wanted to grab the history of the user, which is a List of all history. It is not populated until you ask for that history, and then returns the List.

The example in question was this:

Return a list of users. Each of those users will have a collection of data:
-History
-Roles
-Departments the user is a part of
-Email lists the user is a part of.

You know, I used collections as properties and initialize them when they are first accessed like you did.  However, lets say I wanted to bind any of the collections exposed as properties to a GridView using a ObjectDataSource, I quickly found out that the ObjectDataSource designer didn't allow me to bind to properties of  an object, only methods. So, even though I like your approach, I sometimes shy away from it if I want to do simple drag and drop databinding.

That approach also assumes that we will put properties in every object to coincide with every possible join out there.  There are some cases where a join is not logical in the business object because the data is not really related except in the table.  What if I want to see a list of rows a particular user updated in a particular table, but also the last time the user logged in?  I guess in theory I can have order_status with an updated by user property that points to a user object that points to a user session object that has a logon timestamp.  It just seems to me that every possible join view is not something I want to account for when designing my objects.