Help! How many layers in my app?

[Burt]

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?

Thanks,

Burt

 

[Nicholas Paldino [.NET/C# MVP]]

Burt,

While I advocate architects and what they do, you have to consider the
scale of an app, and the possible future use of the app versus the
investment in time and money to do things properly. You can easily get to
the point of diminishing returns.

For what you seem to be doing, it would seem like the single-project
approach would be fine. However, I can appreciate the architect's point of
view. For example, if this is common functionality in your intranet apps,
why not at least layer out some of the business functionality into classes
in DLL's? That way, you can do mash-ups later in time and revise the UI (or
even create a new one, you aren't linked to ASP.NET or Windows Forms now,
because you have abstracted out the business functionality) whenever you
wish.

Hope this helps.

 

[Peter Duniho]

[...]
Who's right here? Am I just "old school", as he puts it? What are the
best practices?

It would be impossible for anyone here to answer that question without a
LOT more detail about your current architecture.

That said, while I agree that one should be careful to not over-complicate
the design by adding way too many layers of abstraction, it is true that
abstraction is generally a *good* thing. Even if you never wind up
reusing the components elsewhere (and the potential for doing so is a good
argument in favor), by compartmentalizing things at least to some degree
it helps ensure against hard-to-maintain code dependencies and
side-effects.

It's also been my experience that the effort to create suitable
abstractions and separate various code functionalities assists in the
overall thinking about the design. By figuring out where different
components actually need to interface, it also helps in figuring out just
what's important within the design and what doesn't really need to be
implemented.

Anyway, that's just a short story. The fact is that there are indeed lots
of advantages to "layering" the design, as you put it. I can't tell you
whether your architect wants you to layer too much or not...he and you
will have to work that out yourselves. But it's not unreasonable to
expect *some* kind of modularization in your design.

For what it's worth, I've got applications that compiled are under 100K,
and yet which still use multiple projects.

Pete

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[Burt]

Arne and others,

Thanks for much for the comments. I'm familiar with the layers or
tiers you describe (presentation, business logic, db). The ones my
architect is pushing are above and beyond those though. Examples:

-Can't have business logic in the web app. The .Net GUI must
communicate with a web service on another machine. Reason: "None of
our web servers have business logic. This way we can offload the
processing".

-Web service interface should not have any logic. Need to split it
into interface and logic apps. Reason: Can upgrade the business logic
without touching the facade layer.

-Tiers shouldn't call each other directly but through messaging.
Example: you can't call a DTS package directly. Must create an MSMQ
app for this. (Reason given: "Everything must be loosely coupled").

-Apps should preferably involve a BizTalk application which can route
messages (Boy do we have some high paid BizTalk contractors at my
company).

Seems to me that these are all nice buzzwords and sound great in
theory. The reality is though, that my company only handles 20
customer transactions per day. And all of our apps do different
things- one processes loan applications, one moves data to the GL, one
handles expense reimbursements...there isn't much code to share btw
apps.

But it's hard to know where to draw the line at simplicity? Error
handling, using version control, and logging could be eliminated too
to keep it simple, my architect might argue.

Burt

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

-Can't have business logic in the web app. The .Net GUI must
communicate with a web service on another machine. Reason: "None of
our web servers have business logic. This way we can offload the
processing".

Bad advice in most cases - exception is if the business logic for
some reason is nor horizontal scalable.

-Web service interface should not have any logic. Need to split it
into interface and logic apps. Reason: Can upgrade the business logic
without touching the facade layer.

Good advice.

-Tiers shouldn't call each other directly but through messaging.
Example: you can't call a DTS package directly. Must create an MSMQ
app for this. (Reason given: "Everything must be loosely coupled").

Can be good or bad advice depending on the specific requirements.

-Apps should preferably involve a BizTalk application which can route
messages (Boy do we have some high paid BizTalk contractors at my
company).

Can be good or bad advice depending on the specific requirements.

Seems to me that these are all nice buzzwords and sound great in
theory. The reality is though, that my company only handles 20
customer transactions per day.

In that case I think the most important buzzword is KISS !!!!

Arne