N-Tier Structure question

[yurps]

Hello,

I want to create business and data access layer for my website. I am
not sure what the right way to go is, I could use a code-generation
tool, but want to understand a bit more about design.

Basically I have my DAL, BOL, & Website project....

in DAL I have the class OrderDB with a method called List()
which returns a collection object called OrderList which is
specified in the BOL project, where I have OrderList and Order
classes.

In DAL I have a reference to BOL, and in the Website I have a reference
to BOL & DAL. I fill my datagrid much like this...

OrderDB odb = new OrderDB();
OrderList ol = odb.List();
DataGrid.DataSource = ol;
DataGrid.DataBind();

However I could actually add another class to the BOL project, call
Orders which calls the OrderDB.List() as a static method returning a
IDataReader object (I am using Enterprise Application Blocks), then
there I iterate thru it and load my OrderList object and send it to the
UI tier.... so it would go

Orders ors = new Orders();
OrderList ol = ors.GetList();
DataGrid.DataSource = ol; etc..etc...

in this case I have a reference to DAL in BOL, and a reference in to
BOL in Website....this seems to be a better n-tier structure in terms
of referencing and passing thru the layers but does not seem to be the
case here
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

Any thoughts

 

[shiv_koirala]

Hi yurps ,

OrderDB odb = new OrderDB();
OrderList ol = odb.List();
DataGrid.DataSource = ol;
DataGrid.DataBind();

This snippet seems to put too much work on UI. I mean the UI has to
know lot of stuff he
has to know how the DAL works and How the BOL works....Definetly not a
preferred way.


Second snippet just wanted to know why the Orderlist

Orders ors = new Orders();
OrderList ol = ors.GetList();
DataGrid.DataSource = ol; etc..etc...


Simple the orders class calls the Orderdb and iterates and load the
collection
(Orders is inherited from collection base)

Orders ors = new Orders();
ors.GetList();
DataGrid.DataSource = ors;


Shivprasad Koirala
C# , VB.NET , SQL SERVER , ASP.NET Interview Questions
http://www.geocities.com/dotnetinterviews/

 

[brian.fairchild]

Over the past few years I have leaned more towards a seperation of the
UI, Business and DAL. I have always clumped the DAL and Business
Objects together. I have also tried to cut down on what the UI has to
do.

I would suggest you let the UI know as little as possible about the BO
and the DAL. In fact, I would not let the UI even know there is a DAL.
Here's an example of a recent project:

Classes:
Users.DAL
Users
User
UserController
WebApp

The WebApp only ever knows about the UserController. The UserController
only knows about the Users. The Users knows about the User and
Users.DAL classes.

This keeps you code seperated enough that if you decide to do something
differently in your Business layer, that it would be pretty much plug
and play. Say for example you wanted to populate a treeview control
with a list of users nested based on company hierarchy:

UI:
UserController.GetCompanyList(treeview, ConnectionObject, Language);

that's all the UI has to know about. Now in your controller you are
doing something like this:

public static void GetCompanyList(TreeView tree, ConnectionObject conn,
string Language)
{
Users users = new Users(ConnectionObject, Language);
foreach(User user in Users)
{
AddNode(user, currnode);
//add your node to your tree
}
}
public static void AddNode(User user, TreeNode node)
{
foreach(User childuser in user.Subordinates)
{
// ....add node here
if(childuser.Subordinates!=null)
AddNode(user, currnode);
}

}
public class Users
{
public Users(ConnectionObject conn, string Language)
{
DataSet ds = Users.DAL.GetList(conn, Language)
foreach(DataRow dr in ds.Tables[0].Rows)
{
User user = new User();
user.FirstName = ....
this.Add(user);
}
ds.Dispose();
}
}

But by creating the abstraction here of the UserController if you ever
wanted to change what gets displayed to the UI, it's a simple change at
the UserController layer. Or, if you wanted to completely change how
the Users object was filled, say you wanted to get it from XML instead
of a db, then you only have one place to change it.

 

[Kevin Spencer]

A Data Access Layer should be agnostic of a Business layer:

in DAL I have the class OrderDB with a method called List()
which returns a collection object called OrderList which is
specified in the BOL project, where I have OrderList and Order
classes.

This OrderDB class sounds more like a Business object than a DAL object.
What sort of Database object is an "Order?"

In DAL I have a reference to BOL

Again, the DAL should be Business-agnostic. It should have no knowledge of
upper tiers.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.

 

[Nick Malik [Microsoft]]

As others have pointed out, you have your DAL referring to your Business
objects. That's pretty much backward. The Business objects can refer to
the DAL for persistence, but the DAL itself knows nothing about the business
rules... it just knows how to persist.

I have a novel idea: reuse. Why not just reuse the DAL that is built in to
the Enterprise Library? Then you won't have to write one!
(See my blog:
http://blogs.msdn.com/nickmalik/archive/2005/08/01/446395.aspx )

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[yurps]

Thanks for all the replies, I am now confident about what I originally
thought was the case. I guess the link I posted put me off track a
bit.

shiv_koir - the Orders class is not a collection rather it would be
better described as a OrdersController or OrdersManager which has a
static method returning an OrdersCollection....however I do think I can
add a method to my OrdersCollection which will fill it up, and thus
bypass the Controller class.

brian.fairch - I do like you idea of only making this object visible to
the WebUI, but I think it will need a reference to the System.Web.UI
namespace where the rest of the BizObject will not. Are you suggesting
passing a ConnectionObject into the UserController Business Object? I
thought that the DAL would take care of this.

Nick Malik - You are right, in a way my DAL is just a facade to the MS
Application Blocks, I just wrap the calls so they only access the our
apps sprocs and return DataReaders to the BizObject to fill the
TypedCollections or single object instances. This was what made my
initial decision to use them, as I had seen some other code which
allowed DataReaders to be passed between tiers I wanted good framework
to do this like this block provides.
Thanks for the link, basically I have a working website, I am
refactoring the app now as we went quickly from prototype to release so
there wasn't time originally to think about scalable design. More
organisations like developers to have knowledge of the Application
Blocks, so I thought it best to incorporate them even though I have my
own ExceptionHandling & Cryptography implementations. Additionally I
would like to put some elements of Lhoka's CLSA.Net into this so we can
scale out with the component hosted on a separate machine.

 

[brian.fairchild]

I run an app where I need the same object to connect to different db's
of the same structure. That's the only reason I would pass along a
connection object.

 

[Nick Malik [Microsoft]]

There is some semantics here. The important part is that the business layer
doesn't know how an item is stored, and the Data layer doesn't know how an
item is used. GetUsers can be part of your DAL, as long as it doesn't refer
to a business object. The moment it refers to a business object, it is part
of your business layer. Since it pretty much has to refer to the business
objects, it is part of what I would call a "mapping layer" that maps
Relational to OO structures. The key is not to do any work other than
mapping in this layer.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.