The benefits of a 3-tier architecture?

Question

I'm not entirely convinced of the benefits of a 3-tier architecture. Why, then, has LINQ emerged, which is a lighter data access approach? Any input would be appreciated.

Answer 1

You need to do it the naive way and fail before you realize the problems those frameworks and patterns solve.

Happened to me with many things. SVN branches looked like a disorganized way to do things, until one day I wished I had branched before my last 5 commits. C++ templates seemed useless and confusing, until I got enlightened; now I use them pretty often. And every single J2EE feature will look like useless bloat to anyone, until you actually build an app big enough and have problems; then they may be exactly what you need. (thus it's a flaw to "require" you use them)

Answer 2

One of the main benefits of n-tier applications (there are of course many more than what I mention here) is the separation of concerns that it brings. If you structure your application so, that the responsibility for i.e. data access is held in a data access layer (LINQ2SQL is a perfectly good example of one), validation and other business logic in one or more other layers, presentation in yet another one etc., you can change details in, or even replace, an either layer without having to re-write the rest of your applicaton.

If, on the other hand, you choose not to implement an n-tier approach, you'll quickly notice that for example changing the name of one single database table will require you to go through your entire application - every single line of code - in search for SQL statements that need to be updated. In an n-tier application (if you've done things rigth), you'll only have to change the table name once in your code.

Answer 3

Like in most fields of engineering there's never a perfect one-size-fits-all solution for development or architecture. So it is with n-tier architectures.

For example, quite a few applications run perfectly well as a one-tier or two-tier architecture. Microsoft Word, for example, does quite well, thank you, as a single-tier system.

Most business applications have started using layers (as distinct from tiers: layers are virtual, tiers are physical) as it makes life much easier to have presentation logic in one place, business logic in another, and persistence logic somewhere else. It can make sense too depending on the application to have lots more layers: I recently finished up a project with about sixteen layers between the UI client and the SQL database. (We had REST services, co-ordination layers, mixed databases, you name it. Made for quite a deployment challenge.)

The nice thing about all these layers are

• testing becomes fairly easy, as each layer does one and only one thing
• it's feasible to scale, especially if you design your layers to be stateless: then you can group them together and deploy to separate boxes quite easily
• it's feasible to have lots of developers working simultaneously, so long as you keep talkin' to each other
• changes are (usually) limited to one layer in the code

LINQ, the Language Integrated Query, really helps too, as can abstracts away much of the harder parts of working with persistence layers. For instance

• the SQL-like syntax maps fairly directly to SQL database tables or views
• working with more complex non-relational data like XML files is made straightforward

Without LINQ developing persistence layers was invariably repetitive, never a good thing.