Burt wrote:
There's an architect at my 200 person company that advocates having
many layers in all my C# apps. He wants web services, use case
handlers, facade layers, data gateways, etc.
When I ask why all this complexity is necessary, he gives me what if
scenarios: "What if you ever want to access the business logic with
another front end?", for example.
These are typical "intranet apps"...one or more screens selecting and
updating rows in a database, maybe doing some processing. My approach
is a single .Net project with asp.net or fat client front end, c#
class files for the middle tier, and stored procedures for the db
layer.
Who's right here? Am I just "old school", as he puts it? What are the
best practices?
I would start by choosing terminology carefully. The definitions
I prefer is:
tier = something physical separated so that it can but does
need to run on different boxes
layer = something logical separated but still has to run on
the same box
So you have either a 3 tier web app:
browser
web app on IIS/ASP.NET
database server
or a 2 tier fat client app:
fat client app on client PC
database server
Both you web app and fat client app is often divided
in 3 layers:
presentation layer
business logic layer
data access layer
For the web app:
presentation layer = .aspx with tags + .aspx.cs with code behind
business logic layer = .cs with true business logic
data access layer = .cs with some database interface a la DAAB
But note that those 3 layers are only a common used way of dividing
and other are possible.
I actually prefer to consider the same code as 4 layers:
presentation layer = .aspx with tags
control layer = .aspx.cs with code behind
business logic layer = .cs with true business logic
data access layer = .cs with some database interface a la DAAB
And if it is purely CRUD stuff with no real business logic, then
you can do it as 2 layers:
presentation layer = .aspx with tags + .aspx.cs with code behind
data access layer = .cs with some database interface a la DAAB
So:
- you will by definition be using 3 tiers for your web app
- you should definitely use well defined layers to get good
code structure
- but it can be discussed whether to use 2, 3, 4 or 5 layers
- I would expect the architect to be paid to make the decision
on how many layers and which - not the developer
And a couple of loose ends.
The fact client app can be 3 layers:
presentation layer = .cs with win forms code
business logic layer = .cs with true business logic
data access layer = .cs with some database interface a la DAAB
or 2 layer:
presentation layer = .cs with win forms code
data access layer = .cs with some database interface a la DAAB
The database tier can be just 1 layer:
tables
or 2 layers:
stored procedures
tables
Arne