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.EmpCo llection
MyCompany.MyApplication.BusinessLayer.Controllers. EmpController
(I put my controllers in 1 namespace..just a preference I have..
MyCompany.MyApplication.BusinessLayer.EmpLib.EmpCo ntroller 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.Emp DS
(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)
...
"Brent Borovan" <Br**********@discussions.microsoft.com> wrote in message
news:EE**********************************@microsof t.com...
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?
---
Thanks.
