MIX07 Update: The Future of N-Tier Architectures

As a Director of IT, one of my principle jobs is to recruit talent. During our interview process, we start by asking a candidate about a project they designed, coded and deployed and we present them this picture:



The interview discussion focuses on answering what replaces the question mark - what is the appropriate N-Tier Architecture for their application. You can use this question for any developer because its open to multiple solutions - the junior developer might answer that there is an ASP.NET page that connects using the supplied wizards to an ADO.NET connection that then talks to the database. For a more seasoned architect, they should answer with a much richer domain model, database access layer, proxies for web service or other distributed calls, monitoring and configuration management layers, class factories, etc.

That's why the question is an interesting question for interviewers - it forces the discussion to question design decisions. Why did they use ADO.NET? Why did they choose web services instead of remoting? Why did they choose to keep code in separate objects instead of in the code-behind files? Why did they choose particular design patterns, etc.?

As web technologies have evolved is that they have focused on adding maturity in the tiers. A classic ASP site with some ASP page code, some VB 6.0 objects and a connection to the database through ODBC is now an ASP.NET page, a code-behind file, some domain model objects, some ADO datasets, web service proxy classes, etc. Now there are dozens of options on implementation of that middle-tier and the role of the architect is to decide amongst a selection of options which is appropriate for the particular application being built.

What has happened as these technologies have evolved is an explosion of tiers. In the last enterprise application I managed, we had the following tiers: 1) reverse proxy; 2) HTTP handlers/modules; 3) ASP.NET page; 4) code-behind files; 5) value objects or business entities; 6) web service client stub classes; 7) web service handler classes; 8) data access layer objects; 9) Microsoft Enterprise Library; 10) the Database!

At least it was still easier than using classical J2EE! :)

What seems to be happening as Microsoft technologies evolve is a resolving of this tier explosion through a few different strategies:

1. Use of LINQ to simplify data access and consolidate the data tier into some SQL like statements.

2. Code generation techniques for automating plumbing code (the LINQ designer for example will build your domain model simply by pointing at a schema).

3. Smarter web controls that require less code - Dynamic Data Controls for example.

4. Integration of .NET into Silverlight to put more smarts into the client instead of requiring web service calls for every function.

5. Greater focus on Plain Old .NET Objects - LINQ in particular moves from the heavy Dataset based approach that ADO.NET uses as value objects and can instead populate simple lightweight classes that the developer can design as required.

6. Greater focus on declarative languages - LINQ and also use of IronPython and PHP for example. Instead of focusing on imperative languages that specify the algorithms on how to do instructions, a declarative language allows the developer to focus on business rule declaration and specify what is required and delegate implementation to the framework.

7. On the client side, dramatic improvements in rendering in Silverlight especially in 3D based applications.

All these developments are promising. If the technology works as advertised then development of basic plumbing operations such as CRUD operations with a database, web service calls, etc. should be dramatically easier to code and maintain.

However, "works as advertised" is always the challenge. Developers who have worked with O/R mappers for years have experience with frameworks that claim to hide away details but then also hide away performance bottlenecks, poor implementation strategies and developers are increasingly dependent on the framework to work in the background.

And from what I have seen at the conference so far, its really too early to tell - we're still at the "Just use the wizard" stage where Microsoft demos a cool technology by running a dinky unrealistc demo. Don't be the fool to take the sample code and consider it ready for production without some serious design review!