3-tier Design

[Demetri]

I have a 3-tier design question, in particular the Business layer.

Allow me to illustrate in order to convey what my question is.

Lets say we have a database with two tables. The Orders and OrderDetails
table.

Lets say we have two pages:
Page1: Has a grid that shows a list of orders.
Page2: Shows the Order details.

What entities would you create? In tradition, I would think there would only
be one Entity (Order and OrderCollection). So then, how would one represent
the details?

In addition, lets say Page3 shows the same info as Page2 with the exception
of additional fields such as some aggregate totals.

I can not see making an entity to represent each and every way Order
information may be retrieved from the database. You may have several stored
procedures:
GetOrders
GetOrdersWithTotals
GetOrderDetails
GetOrderDetailsWithTotals
GetOrdersWithSomeOtherData
GetOrdersWithAnotherSetOfData
Etc...

So how many Order type entities is necessary?

I stay away from having the UI reference any data elements or namespaces
such as System.Data or my DAC layers. The only references it has is the
Business or Service layers.

Is there a web site (wth source code) that illustrates a true 3-tier object
model?

--
-Demetri

[tdavisjr]

"Demetri" <De*****@discussions.microsoft.com> wrote in message
news:95**********************************@microsof t.com...
Look at the PetShop 4.0. Its a good reference application for what you
trying to do.

I have a 3-tier design question, in particular the Business layer.

Allow me to illustrate in order to convey what my question is.

Lets say we have a database with two tables. The Orders and OrderDetails
table.

Lets say we have two pages:
Page1: Has a grid that shows a list of orders.
Page2: Shows the Order details.

What entities would you create? In tradition, I would think there would
only
be one Entity (Order and OrderCollection). So then, how would one
represent
the details?

In addition, lets say Page3 shows the same info as Page2 with the
exception
of additional fields such as some aggregate totals.

I can not see making an entity to represent each and every way Order
information may be retrieved from the database. You may have several
stored
procedures:
GetOrders
GetOrdersWithTotals
GetOrderDetails
GetOrderDetailsWithTotals
GetOrdersWithSomeOtherData
GetOrdersWithAnotherSetOfData
Etc...

So how many Order type entities is necessary?

I stay away from having the UI reference any data elements or namespaces
such as System.Data or my DAC layers. The only references it has is the
Business or Service layers.

Is there a web site (wth source code) that illustrates a true 3-tier
object
model?

--
-Demetri

[sloan]

I have an example at:

http://sholliday.spaces.msn.com/PersonalSpace.aspx 6/5/2006
5/24/2006 entries

2.0 and 1.1 respectively.

You would do 2 entities.

class Order
private m_orderID;

class OrderDetail
private int m_orderDetailID;
private int m_parentOrderID;
the Order class will have a subcollection object.

class Order
private OrderDetailCollection m_allOrderDetails;
The example is brief, but blog has downloadable code against the Northwind
database for a complete look/view.

"Demetri" <De*****@discussions.microsoft.com> wrote in message
news:95**********************************@microsof t.com...

I have a 3-tier design question, in particular the Business layer.

Allow me to illustrate in order to convey what my question is.

Lets say we have a database with two tables. The Orders and OrderDetails
table.

Lets say we have two pages:
Page1: Has a grid that shows a list of orders.
Page2: Shows the Order details.

What entities would you create? In tradition, I would think there would only be one Entity (Order and OrderCollection). So then, how would one represent the details?

In addition, lets say Page3 shows the same info as Page2 with the exception of additional fields such as some aggregate totals.

I can not see making an entity to represent each and every way Order
information may be retrieved from the database. You may have several stored procedures:
GetOrders
GetOrdersWithTotals
GetOrderDetails
GetOrderDetailsWithTotals
GetOrdersWithSomeOtherData
GetOrdersWithAnotherSetOfData
Etc...

So how many Order type entities is necessary?

I stay away from having the UI reference any data elements or namespaces
such as System.Data or my DAC layers. The only references it has is the
Business or Service layers.

Is there a web site (wth source code) that illustrates a true 3-tier object model?

--
-Demetri