3 tier architecture in .NET web applications

Question

Nowadays most systems are designed as web apps. In the .NET world the famous three tier architecture is usually translated like this.

• Front End (Web Application)
• Middle Tier (custom DLLs using an ORM to access and process data)
• Back End (SQL Server, Oracle, MySQL)

To me, the middle tier is not actually the middle tier because regardless of how isolated the mid tier is, it executes in the context of a web server (as it resides in the DLLs) and essentially a part of the web application.

My Questions:

1. Is it correct to say that a 3 tier arch is a simple 2 tier arch?

2. Is it correct to design the apps, that requiring heavy data processing, with no physically separate middle tier?

3. What options are available for the middle tier other than hosting it in WCF or Windows Service?

Answer 1

To me, the middle tier is not actually the middle tier because regardless of how isolated the design is and how stateless the DLLs are, they execute in the context of a web server only and essentially a part of the web application.

No, the middle tier could be in another server(s) altogether when it comes to large applications. For example you might be hosting the web frontend in one server and communicating with another server where domain model logic is hosted. Also depending on the demand of your system it could be multiple servers.

Is my observation and understanding correct that 3 tier arch is not really a 3 tier but a simple 2 tier arch?

Refer to the previous comment.

Is it correct to design the apps this way when there is no technical middle layer, even the applications that require heavy processing?

When heavy processing is required, it would not be optimal to use the web server to do the processing, as it would affect user experience and they may notice the web site is 'slow'. You could always delegate heavy/time consuming processing to some another server and display result to the user appropriately (push instead of waiting screen)

Current is the only option for middle tier for a web app is a windows Service and nothing else?

1. It could be application server with exposed web service
2. Scalable roles (similar to microsoft azure provides) subscribed to a queue

Answer 2

Whether you place the "Middle Tier" code in DLLs loaded by the Front End site or place it into a separate web service application is just a detail. This placement decision does not change the code architecture in a meaningful way. It's more of a deployment decision.

1. No, the tiers are not defined by physical deployment decisions but by code architecture and data flow.
2. I'll replace the word "correct" by "advisable" in your question and answer that one. What's advisable is what allows you to be most productive. A "Middle Tier" is used when needed (it is not strictly required). For example it can be helpful to untangle logic from UI code and it can allow for having multiple Front Ends using the same business logic.
3. Again, you can place the "Middle Tier" code anywhere you like. It can be in a DLL, in a WCF web service or in a Windows Service. This is purely a deployment decision. Relevant concerns are simplicity, fault isolation, security and performance.

The term "Back End" means many things to different people. Complex real-world systems often consist of many components. There often is not a single component you can identify as the "last layer". "Back End" is a relative term.

Answer 3

We know that nowadays the systems are designed as web applications. Every imaginable system is either converted or planned to be converted to a web app.

Huh?

While web apps are certainly quite popular and useful, they are by no means the be-all-end-all. Here are some cases where web apps are a poor choice and a "desktop" app would be a much better fit:

• Intensive client side computation. Imagine a team of 50 astrophysicists all working together plotting an extremely intricate spacefaring mission. Now imagine that their equation system solving tool (e.g. WolframAlpha) is a web app. Do you really want a queue of jobs that each take minutes or hours to compute sitting around on the webserver? And consider that most of these jobs are going to be interim results, not the final answer, so many calculations need to be performed in a serial fashion. A web app would destroy productivity; calculate on the client and only push end results.
• Complicated or cascading validation rules. As a user, if I have to make 20 or 30 calls out to the webserver for validation checks when entering data, I'm going to get impatient with the app very quickly, even if each call only takes tens of milliseconds. Additionally, if the business objects are in C#, it's really aggravating to have to reproduce (and test) all the validation logic in JavaScript. A fat client prevents that code duplication and reduces user wait time.
• Very high levels of security. Say a classified government facility wants to pre-encrypt all data before any transmission or storage occurs. Tightly securing data through a web application is difficult. A web app has a greater attack surface than a desktop app. And then the webserver has to decrypt the data, perform its operations, then encrypt again before storage. Or the client could do everything and push the finished encrypted data to the DB.
• Minimizing maintenance and resource usage. A web app means you need a web server. But say the requirement is for a simple CRUD app that's only used in a single physical office, and the app rarely if ever changes. The users don't care if they're looking at a browser or a locally installed executable. Why complicate things by adding unnecessary components? Removing the web server from the equation makes the system simpler (meaning less chance of breakage), and reduces server and bandwidth usage.

In (very simplified) terms of three tiered architecture, the difference between a "web" and "desktop" app is where you put the middle tier: client side or server side. All of the examples above support three tiers, despite having only two physical machines (a client and a DB), because there's a difference between logical and physical tiers. If it helps, you can initially think of them as focusing on two different domains: design and deployment. Understanding these differences is an important part of system architecture and design.

Say I have a web app and find that users in Europe heavily consume a particular critical service, but the US users almost never use it. My web app servers are located in the US and can't be moved. If my middle logical tier is tied to my web app's servers, I can't break out the service and move it to a different physical location to improve EU performance. But if things are logically separated properly, I can change the physical middle tier without affecting the system's logical architecture at all.

To me, the middle tier is not actually the middle tier because regardless of how isolated the design is and how stateless the DLLs are, they execute in the context of a web server only and essentially a part of the web application.

You're conflating physical and logical tiers. If your middle tier is part of the context of the web server, then you don't really have a middle tier; you have a complex web app and a DB. If it simply resides there, then you have three logical but two physical tiers.

Is it correct to design the apps this way when there is no technical middle layer, even the applications that require heavy processing?

The only possible answer to this is "it depends", specifically on the requirements and use cases. You have a simple CRUD app? Then a middle tier probably isn't necessary (either physically or logically). Even my "heavy processing" example above functions fine on two physical tiers. But here's a real world example I worked on which would have been impossible without a middle tier: a very big client had many users in many different countries who needed many different reports. Different reports accessed different DBs and had different processing and run time requirements. So we used a middle tier which created and managed a job queue and generated the reports. Key points about why a middle tier was important:

• It provided an abstract interface to the UI tier, easily able to be consumed by web or desktop apps (we had both).
• It made it easy to make priority and scheduling decisions about which data to fetch from the DB and when. We had some very contentious tables, and blindly submitting many large requests for report data would kill performance.
• It did work which was impossible to accomplish on the other two logical tiers. The DBs couldn't generate the reports and the clients couldn't manage the queue.
• It saved doing work on the other two physical tiers. We had a lot of data which needed to be globally accessible, so pushing all of it to the client and generating the report there was not feasible. We also had very busy DBs; the DBAs would have murdered us if we'd cut out a chunk of the servers' resources for executing middleware on a VM or demanded a bunch of complicated, resource intensive jobs to run a custom queue.

Current is the only option for middle tier for a web app is a windows Service and nothing else?

Not at all. Your middle tier can be designed and deployed as almost whatever you want it to be, as long as it sits between and is distinct from the client and storage tiers. Web services, console apps, Linux servers... the list goes on.

Answer 4

There is a distinction between "Logical Architecture" and "Physical Architecture", you can have the same code base and yet deploy it on a Web Tier and Middle Tier, or just strictly on the Web Tier.

What you decide is based on a myriad of factors. If your Web Tier is merely a pass through to call more or less mirror services on the Middle Tier, then it would appear to me that the Middle Tier is pointless. Such an unnecessary physical architecture adds to Hardware Cost since most Enterprise level applications require redundant servers at all tiers. Also complicates Deployment and Maintenance. Keep the End Goal in mind, you can build the greatest App, but if complex deployment and maintenance eats away from your Development Time, then is it worth it? That middle tier Server would be better served as another Load Balanced server on the Web Tier. Also network latency overhead is the slowest and most unreliable between tiers, whereas if you call in memory JARS or DLLS without crossing process boundaries, or remoting via network, then obviously processing and response time would be the fastest for higher traffic scenarios.

However its not a one size fits all to every solution. For certain functionality within the Application you may need Message Queues or Backend Services or Chron Services or Windows Services. Such as for disconnected workflows, or long running intensive processing. Which may indeed be considered a Middle Tier or "another" tier outside of the Web Tier for other Business Services.

The best rule of thumb is to never over-complicate over-engineer what is necessary for the business. Simple works, complex fails.