CustomerCollection and OrderList

Nov 3, 2010 at 4:54 PM

You have two tables, Customer and Order. Customer table has zero or more Customers. Order table has zero or more Orders.

Each Customer has zero or more Orders. Likewise, each Order has one or more Customers. This is a 1:N Relationship.

The generated code will create an OrderList on a Customer object to signify that you can loop through related Order objects.

Suppose we have 100,000 Customer and 300,000 Orders, what happens when we create the CustomerCollection? The CustomerCollection will have 100,000 customers and the OrderList will have 300,000 orders (right?)

The part I'm wondering about is... What if there is 300,000,000 Orders, is there going to be a performance hit when the CustomerCollection is created?

Or, is the OrderList created if we walk the relationship from the Customer to the Order?



Nov 4, 2010 at 6:37 PM

When you load the customers collection, no orders are loaded. If you access a Customer.OrderList then it will be loaded at that time. This is the lazy loading feature. Also to keep referential integrity all order for all loaded customers are loaded. So yes if you have loaded 100,000 customers you will get all orders for these customers. This is why usually you will want to load only the customers you are working with. This goes for any data-loading framework.

If you do not want to use lazy loading, you can explicitly load customers and order at the same time. You can create a subdomain, which is a container in which all objects loaded. Then explicitly define what should be loaded. Notice below that I have selected all customers and then all order by customer id. These are predefined select commands based on the relations in the model. Yu can follow the pattern and add your own of course as well.

SubDomain subdomain = new SubDomain();
subdomain.AddSelectCommand(new CustomerSelectAll());
subdomain.AddSelectCommand(new OrderSelectByCustomerPks());
var customerList = subdomain.GetCollection<CustomerCollection>();

Obviously all of these objects are loaded into memory so I would suggest not loading 100,000 customers. This is a nice pagination system built into the framework so load only what you need in the methods you are building.

If you need to bulk update data there is no reason to load objects at all. Simply use the syntax for bulk update. The following example shows how to update all first names for people with an email address of “”. This updates many records without loading the data into memory. The caveat is that it only works on one field at a time. You define a field, a where statement, and a new value. Good news is that it is a lambda syntax so it is compile time checked.

CustomerCollection.UpdateData(x => x.FirstName, x => x.Email == "", "John");

Nov 4, 2010 at 7:59 PM

Thank you. You answered my questions perfectly.