Ted Neward wrote a good article on MSDN about distinguishing layers and tiers in system design. This is to be his first article in a series of articles about Pragmatic Architecture.

The article has some pretty good points about the over-use of n-tier architecture, which I will admit to using more often than necessary. His article goes on to say that a separation of concerns is not itself a bad idea, but rather, the popular implementation of using separate assemblies spread over multiple machines (for example, a client’s machine, an application server, a database, etc.)

A previous project I worked on implemented a rich-client system containing a user interface executable, a few too many business layer DLLs, and a separate data access layer DLL — all installed on the client’s machine. At the time, I was graying the distinctions between layers and tiers. While my design had loose coupling, I was taking a significant performance hit by using several separate DLLs to separate the concerns instead of relying solely on the .NET namespaces.

The point of Ted’s article is to show that, in a design like the one described above, it is better to use logical layering (layers) rather than physical layering (tiers); however, in other designs, the use of n-tier architectures may be preferable. This is a good concept to remember, as it can save time and effort later down the road during performance tuning.