Nemisis wrote:
hi guys,
Currently converting an old classic asp system to a OOP asp.net
application. We are building the new application using a 3 tier
arcitecture and i was wondering about the following.
I have a parent class, that when inserted, inserts a few child classes
into the database, based on other classes. In the old system, this is
wrote as one big SQL script, with many inserts and updates because the
system was not wrote as OOP.
Since we are now moving to an OOP design, am i right in thinking that
we should write this code within the Business tier, using objects?? or
does it not really matter? I am wondering about the best practices for
this?
Anyone? Thanks again
What I generally do is create a class for each business object. For
example there would be a Order object and an OrderDetail object. The
classes themselves know nothing of the database. They simply contain
the data for the order and its details. We call these Value Object
Next I create Data Access layer that knows how to take a Value object
and insert, update, deleting and selecting it from the database. The
data layer knows nothing of business rules. It simply knows how to get
and save each Value object type in the database. The data layer
contains all the SQL queries and boilerplate to connect to the the
database We call these data providers.
Lastly there is a business controller. The controller knows when to
call the data layer to save the value objects or how to call the data
layer to retrieve objects. If the business controller selects an Order
object, then it also calls the data layer to select the order details.
It also enforces the business rules for each object.
The UI would then reference the Business Layer and would not know
anything about the data access methodology or business rules. It would
simply handle the presentation of the individual objects on the screen.
Here is an example:
//Value Objects
class Order
{
int OrderId;
List<OrderDetai lDetails;
}
class OrderDetail
{
string description;
string quantity;
}
//Data Layer
class SQLOrderProvide r
{
Order GetOrderById(in t id);
List<OrderGetAl lOrders();
void InsertOrder(Ord er o);
List<OrderDetai lsGetOrderDetai ls(Order o);
}
//Business Layer
class OrderController
{
private SQLOrderProvide r _orderProvider;
Order GetOrderById(in t id)
{
Order o = _orderProvider. GetOrderById(id );
o.Details = _orderProvider. GetOrderDetails (o);
return o;
}
List<OrderGetAl lOrders();
void InsertOrder(Ord er o)
{
//perform business logic and validation before calling data
layer
_orderProvider. InsertOrder(o);
}
List<OrderDetai lsGetOrderDetai ls(Order o);
}
We sometime code the business controller against an interface so that
can provide implementations for SQLServer, or Oracle and the back end
can be changed just by dropping the appropriate assemblies.
This is the classic 3 tier setup. It's possible that you would have
other tiers depending on the complexity of your project and your
business rules.
Hope this helps some.
Good Luck
