Basic object design help

[Mike]

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]]

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.

 

[Mike]

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,

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.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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]]

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.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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,

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.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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

 

[sloan]

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.

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,

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.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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

 

[Mike]

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,

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.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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,

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.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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]]

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.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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,

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.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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

in message 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.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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

 

[Mike]

Thank you. I've also looked at sloan's link, which has helped me clarify
things too.

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.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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,

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.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote in message
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.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

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

 

[Lew]

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.