.NET Forum / Languages / C# / October 2007
Basic object design help
|
|
Thread rating:  |
Mike - 08 Oct 2007 11:50 GMT I'm trying to get my head round designing business objects in C# to use with an ASP.NET application. For example, I have a table in my db for Adverts. The fields look like this:
AdvertID int PK AdvertTypeID int FK IssueID int FK PageID int FK OrderID int FK
There's a bit more than that, but the point I want to illustrate is that the majority of the fields are FKs on other tables. It's easy to see which values I need when thinking of inserting or updating the object's data, but when I want to get an Advert object (or a collection of them for display) I need to do a join in the SQL to bring in values from related tables for eg the AdvertType that is related to the AdvertTypeID. Therefore, my question is, does string AdvertType belong as a property of Advert as well as int AdvertTypeID?
Does anyone have any good links that will help me clarify this in my head?
Mike
Nicholas Paldino [.NET/C# MVP] - 08 Oct 2007 14:10 GMT Mike,
Typically, for objects, you would have another object that represents the Advert, the Issue, etc, etc. Think of the foreign keys as a reference (which in a way they are). In .NET, they would reference the object that holds the attributes for that object.
Of course, this is not set in stone, but this is what you will see commonly. Additionally, you will see this information lazy-loaded when it is needed, since the amount of work required to load all the related fields for all the references (and remember, references can contain more references, etc, etc) might be time consuming if all the attributes of all the nested references are not used.
 Signature - Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com
> I'm trying to get my head round designing business objects in C# to use > with an ASP.NET application. For example, I have a table in my db for [quoted text clipped - 18 lines] > > Mike Mike - 08 Oct 2007 14:37 GMT Thank you Nicholas.
If I understand you correctly, what you are saying is that if I want display an Advert with its OrderDate and AdvertType, I have to first instantiate my Advert object, then use its OrderID property as a parameter in instantiating an Order Object, from which I can retrieve the OrderDate, and then do something similar with the AdvertType object. Is that correct?
This seems inefficient to me. Each SQL statement will be incredibly simple, but I will be firing 3 calls to the database instead of one. I've misunderstood something somewhere, haven't I?
Mike
> Mike, > [quoted text clipped - 33 lines] >> >> Mike Nicholas Paldino [.NET/C# MVP] - 08 Oct 2007 14:50 GMT Mike,
No, you haven't misunderstood. Like I said, it's a very common pattern, but it's not a requirement. You would have a property on your Advert object named Order, which would expose an Order instance, etc, etc. The Advert object would have the foreign key for the Order information which is used to obtain the data for that object.
It's not really inefficient when you don't know the usage pattern of the objects.
However, in this case, you seem to know what the pattern is, so you can create something specialized. That's the issue with something that is specialized though, it's good for only that case, not a general case. You can code for that case, but it would not be applicable beyond that case.
 Signature - Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com
> Thank you Nicholas. > [quoted text clipped - 48 lines] >>> >>> Mike Mike - 08 Oct 2007 15:19 GMT Right. Now I have a conundrum. Logically (and aesthetically), I like the idea of this type of business object. What I don't like is the idea of hitting a database numerous times to get the related data (objects). Should I be thinking about creating a base Advert.cs using the properties I already listed, then inheriting from that to create new classes that include the AdvertType, OrderDate and IssueDate etc properties which I can populate using JOINS in one call?
Thank you.
> Mike, > [quoted text clipped - 64 lines] >>>> >>>> Mike Nicholas Paldino [.NET/C# MVP] - 08 Oct 2007 15:43 GMT Mike,
If you are looking for a generic mechanism, then no, I would not go this way. If you are looking for a very specific solution for a very specific operation, then I would say yes, this would be a good way to go.
 Signature - Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com
> Right. Now I have a conundrum. Logically (and aesthetically), I like the > idea of this type of business object. What I don't like is the idea of [quoted text clipped - 75 lines] >>>>> >>>>> Mike Mike - 08 Oct 2007 15:59 GMT Thank you. I've also looked at sloan's link, which has helped me clarify things too.
> Mike, > [quoted text clipped - 82 lines] >>>>>> >>>>>> Mike Lew - 08 Oct 2007 16:24 GMT >>>>> If I understand you correctly, what you are saying is that if I want >>>>> display an Advert with its OrderDate and AdvertType, I have to first [quoted text clipped - 6 lines] >>>>> simple, but I will be firing 3 calls to the database instead of one. >>>>> I've misunderstood something somewhere, haven't I? In addition to the other fine advice, I suggest that you don't necessarily need to inherit.
Sometimes you model foreign key (FK) relationships as an object representing the "master" table with a collection member that represents rows from related tables. The contained collection contains objects that "have a foreign key" to the containing object.
So in your example, an Advert object, corresponding to a single AdvertID, could be part of a collection within an Order object. The collection represents all Adverts connected to the current Order of interest.
This may not be optimal for your situation, but it is handy for things that follow a "header / detail" pattern, such as "order with line items".
Such a structure can be filled via a JOIN query to save database hits, although that can risk huge result sets.
 Signature Lew
sloan - 08 Oct 2007 15:03 GMT You only need 1 call to the database. With 3 ResultSets.
Find a complete working example of this at:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
Customer has Orders. Orders have OrderDetails.
...........
One thing I do differently now (not shown in the example above) is this
instead of List<BusinessObjects.Order> all over the place, I create a class like this:
public class OrderCollection : List<BusinessObjects.Order> { }
> Thank you Nicholas. > [quoted text clipped - 48 lines] >>> >>> Mike
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|