Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / October 2007

Tip: Looking for answers? Try searching our database.

Basic object design help

Thread view: 
Enable EMail Alerts  Start New Thread
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 Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.