N-Tier question

[Guest]

Posted on behalf of a team member:
Our organization is in the enviable position of starting a new web-based
product with a clean slate working with the latest ASP .NET tools (VS 2005
Pro using ASP 2.0). We have been researching the best practices for creating
an N-tier application and have found several varying viewpoints as to how
proceed, which leaves us wondering which specific model is easiest to build
and maintain with the latest and greatest. We are very comfortable with
stored procedures and building a solid object class library and BLL on top of
that, and would naturally tend towards this methodology. That being said, we
don’t want to count out a much more easily built and maintained methodology.
Is there a suggested standard for building N-Tier web applications?

 

[Guest]

Sounds just fine to me.
Peter

 

[Karl Seguin [MVP]]

Agreed...and at the rick of starting a debate, don't use datasets (typed or
untyped) Simply use datareaders a datareader and have ur DAL map it to
actual classes.

karl

 

[Guest]

It sound like you've got a good basic understanding of what you need to
build. For a more advanced understanding of middle tier designs in .NET I
suggest you read this high quality book on the subject:

Expert VB 2005 Business Objects, Second Edition (Expert) (Paperback)
by Rockford Lhotka

http://www.amazon.com/gp/product/15...103-1486542-0380601?s=books&v=glance&n=283155

 

[sloan]

I do this:


(biz)
public class Emp{}
public class EmpCollection{}

(data)
public class EmpData{}

(back in the biz)
public class EmpController{}


Emp is the business object.
EmpCollection is a collection of Emp objects.

EmpData (I put mine in its own assembly) is the data layer object.

EmpController is the business layer object..which returns Emp and
EmpCollection objects... and ~talks to EmpData

full names:

((MyCompany.MyApplication.BusinessLayer (assembly) ))
MyCompany.MyApplication.BusinessLayer.EmpLib.Emp
MyCompany.MyApplication.BusinessLayer.EmpLib.EmpCollection
MyCompany.MyApplication.BusinessLayer.Controllers.EmpController

(I put my controllers in 1 namespace..just a preference I have..
MyCompany.MyApplication.BusinessLayer.EmpLib.EmpController might be good
too)
....
((MyCompany.MyApplication.Data (assembly))
MyCompany.MyApplication.Data.EmpDataLib.EmpData

...

I also put my DataSets (strong typed) outside of these assemblies

MyCompany.MyApplication.Data.DataSets.EmpDSLib.EmpDS
(if I need them...sometimes I don't need DataSets..it depends... I usually
use them in a web app, more than a winforms app)

...

I put Framework pieces in

MyCompany.Data

or
MyCompany.Framework.UIFramework (as an example)

framework pieces are the common code.. that lives "above" and outside any
application specific code.

...

95% of the time, I don't use DataSets. I never use untyped DataSets.
***On occasion***, esp in the web area... I used a strongly typed dataset..
Why?
DataSet.Select("","LastName,FirstName,Age DESC");

Having a multiple parameter sort is nice.
Writing a super complex IComparer sometimes is a pain.

Other than this occasional need, creating strong typed
objects...CollectionBase's is where I am at these days.

I write always have a
private MyCustomCollection ConvertIDataReaderToCollection (IDataReader idr)
method.
This way, I can get an IDataReader in different ways. (1 emp, 10 emps based
on dept, all Emps) from the db...and always get back a collection of Emps
(MyCustomCollection in this sentence, but I call it EmpCollection above).

...

My general rule of thumb is that a strongly typed DataSet is a "poor mans
business object and/or collection".
But sometimes it meets a need.

The other time I use it is with ... large related data.

Lets say I have 100 emps. and 10 depts.
If I do a strictly object design with Emp... Emp has to have an
Emp.DeptCollectionAllDepts

That means.. if I have 100 emps... I have 100x10 depts floating around.
With a dataset, I related to DataSet tables... by a deptid. and only have
to keep 100+10 records around.

I could use the FlyWeight design pattern..but thats alot of work for keeping
track of depts an employee might need to pick from.

(http://www.dofactory.com/Patterns/PatternFlyweight.aspx)




...