The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How do you fill your entity data for browsing?

Consider the following (C#):

CustomerEntity customer = CustomerDAL.GetCustomer(123);

GetCustomer() executes "select * from tbCustomer where pkid=123;" and fills all CustomerEntity members (PKId, Code, Name, Address, etc).

We also have (for browsing only):

List<CustomerEntity> customers = CustomerDAL.GetByState("NY");

GetByState() executes "select PKId, Code, Name from tbCustomer where State='NY';" and fills only the three members above.

This is ugly, but that's what we have. Do you guys have a different approach? I think we could:

1) Create a new customer entity for browsing
2) Return a dataset instead of List<CustomerEntity>

Thanks in advance.
Friday, October 19, 2007
Funnily enough, today I'm changing a system from using approach (2) to using approach (1) instead.
The DataSet option was quicker to develop initially and served us well for some time, but now we wish to expose some results via web services for consumption by other applications, and here the lightweight custom entities work better for us.
Ian Nelson Send private email
Friday, October 19, 2007
We've gone with option #1 in our custom ORM framework. In our code, the DAL.Customer class represents a definition of the Customer table that contains ALL of the fields. A Customer domain object then contains a static "table adapter" that can map properties to one or DAL.Customer fields.

So, we can have a listing object that maps to only to fields {Id, Name} like this:

CustomerListing c = CustomerListing.SelectById(123);
Console.Write("Id: {0}", c.Id);
Console.Write("Name: {0}", c.Name);

Or we can use the full Customer domain object which maps to all of the fields in the Customer table that are needed for editing:

Customer c = Customer.SelectById(123);
Console.Write("Id: {0}", c.Id);
Console.Write("Name: {0}", c.Name);
Console.Write("Address1: {0}", c.Address1);

In both examples above, the static methods called SelectById() are using that domain class's statically defined table adapter that describes that class's property/field mapping with DAL.Customer. So, only the fields that are needed are actually selected.
Wayne Bloss Send private email
Friday, October 19, 2007
Return an IList instead of a concrete List.
It's more flexible.
xampl Send private email
Friday, October 19, 2007
Hi guys,

Thanks for the replies. I created a custom class to handle browsing. It's really easy to implement and our code looks a LOT better. :-)
Monday, October 22, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz