n-tier decisions

Hi all,

I have read much on n-tier design, specifically, choosing TableAdapters and
Datasets or choosing Custom Business Objects. I have spent 3 weeks reading the
pros and cons and have still not started coding for fear of going down the wrong
road. I know that a lot of answers will be 'depends on your application' but
your help is appreciated.

1. how much more time, realistically, does it take implementing the DAL using BO
than TableAdapters?

2. regarding Custom Business Objects, are there any template classes that I can
use that expose the typical functionality and structure, such as a sorting
function, filtering function etc (i.e. those commonly used functions a dataset
has) so I can learn from it and apply it?

3. Is using TableAdapters now less of an issue in .net 2.0 due to partial
classes (i.e. you can customize your DAL a bit better by adding 'behaviour')?

 My fear for going down the TableAdapter route is that once I have the
opportunity to deliver a larger project and to busier sites, I may need to
reconsider the whole DAL design because getting thousands of rows instead of
hundreds starts to introduce performance hits (whether they are visible to the
eye or not)
However, the community seems to ‘favour’ the Custom Business Objects
approach and with that, Datasets and TableAdapters might just get improved (as
they have done in 2.0) to represent a more OO approach and become more efficient
which would make me move back to Datasets and TableAdapters.

My reading has included...

1.    http://msdn2.microsoft.com/en-us/library/aa479317.aspx (On the Way to
Mastering ASP.NET: Introducing Custom Entity Classes)
2.    http://www.asp.net/learn/data-access/ (uses DataSets and TableAdapters)
3.    http://weblogs.asp.net/scottgu/archive/2006/01/15/435498.aspx (Building a
DAL using Strongly Typed TableAdapters and DataTables in VS 2005 and ASP.NET
2.0)
4.    http://dotnetjunkies.com/WebLog/chrisdonnan/archive/2005/11/13/133706.aspx
(Arguments for Dataset and Business Entity Objects for the DAL)
5.    http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416 (Building Layered
Web Applications with Microsoft ASP.NET 2.0)
6.    http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=428 (Implementing
Custom Sorting with N-Layer Design Classes and the GridView)
7.    One common way is to handle all errors in the web application. Simply
throw errors when appropriate in the Bll and Dal layers, and catch them globally
in the Global.asax file using Appliction_Error. My book ASP.NET 2.0 Instant
Results discusses this in more details.
8.    http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=390 (Using Attributes
to Improve the Quality and Usability of Your Code Part 1 - Decorating Business
Objects for Data Binding)
9.    http://blogs.msdn.com/fxcop/archive/2006/04/27/585476.aspx (Why does
DoNotExposeGenericLists recommend that I expose Collection<T> instead of
List<T>?)
 

I will only ever really be delivering to SME companies, not Enterprise level. I
am in a bit of a pickle over this and need to get going on my project and your
help and direction will be very useful. Thank you for your time.

ElCapitan:I know that a lot of answers will be 'depends on your application' 

The answer to your question is "it depends". :-)


One of the other things you might like to look at in terms of business objects
is Linq To Sql.  It basically builds the dumb classes that feature in Imar
Spaanjaar's articles, and so speeds up that kind of approach dramatically.

You may get different answers from different people that reflect their
preference.  I suggest that you try all these approaches to find out for
yourself which one sits most easily with you.  Personally, I don't like typed
datasets.  But that's me.

From my experience the projects that we have taken the extra time upfront to use
business objects over Table Adapters or Datasets or even LINQ to SQL have been
easier to maintain and better performing.  Business Objects really lend
themselves to use case and behavior centric design and development.

While the answer does depend on what you are implementing, the case for using
business objects is strong.  Considering how often Microsoft changes its data
access technologies, you do not want to make one of these technologies the
cornerstone of your application.  This is where a layered applicaiton design
will help you and business objects will sheild the rest of your application from
the DAL implementation details.

If you have not already looked into the CSLA framework http://forums.lhotka.net/
I highly recommend it.  This free framework allows you to develop business
objects that support rich data binding, encapsulation of your busniess rules,
and any DAL technology you want (datareaders, LINQ to SQL, Datasets, Table
Adpapters, NHibernate, etc.)

Hope that helps.

Well I look at it like this. Business objects are almost always superior, but to
really leverage them you need to develop sound architecture and processes. This
takes a lot of time up front, but on subsequent projects it will be the gift
that keeps on giving if you implement some sort of code generation into your
process. This can get you from the database to the UI in no time so that you can
concentrate on the fun stuff. Right now we manually create tables and views in
the db and from that I can auto generate CRUD stored procedures, DAL objects,
BLL objects, and unit tests.

It also encapsulates your design so that you're not tied into specific .NET
objects, this not only helps if you have to do cross platform stuff, but also if
you want to utilize new underlying technologies.

Do you really need n-tier? Do you have sufficient business rules to justify the
additional complexity? If you do then fine, but clearly define how your
application to be developed. Please very close attention to Mike's comment: 

>I suggest that you try all these approaches to find out for yourself which
one sits most easily with you

Just because you need to adopt 3-tier, does not mean you should adopt a
methodology recommended by inhabitants on an ivory tower - find an approach that
works for you. This will means trying various alternatives and ditching all but
one.  A failure to invest time in evaluation various alternatives will cost you
more later if a bad architecture just burns up your developer's time.


If you find you no longer need n-tier then then go for a simple UI project plus
data layer project type solution.