3-tier architecture with 3-server architecture

I am creating a traditional .NET MVC site, so I have a natural 3-tier architecture of software architecture (presentation in the form of representations, a business layer in the controller and a data layer in the models and data access layer).

When I deployed such sites, it usually goes either on one server (where the website and db live), or on two servers (the web server and a separate db server).

How to go about a three-server architecture (WEB, APP and DB)? Will the web server have only a presentation (for example, physical View / aspx pages), the application server will contain the configuration file and the bin folder, and the db server will remain as it is?

My question is basically, can you just move / bin and all applications to a separate server from view views? If so, how do you configure the servers to know where to look? If there is a good primer somewhere or someone can give me a low price, I will be forever obliged.

+4
source share
5 answers

MVC is not a three-tier architecture. Not every solution should be three-tier or n-tier, but it is still important to understand the difference. MVC has 3 main elements, but these elements do not work in a "multilevel" way, they are interdependent:

Model <----- Controller \ | \ v ---- View 

The appearance depends on the model. The controller depends on the type and model. Thus, these multiple dependency paths do not function as levels.

Typically, a three-tier solution is as follows:

 Data Access <--- [Mapper] ---> Domain Model <--- [Presenter/Controller] ---> UI 

Presenter / Controller is somewhat optional - in Windows Forms, for example, you usually do not see it, instead you have a smart client user interface, which is also OK.

This is a three-tier architecture, because each of the three main levels (Data, Domain, UI) has only one dependency. Classically, the user interface depends on the domain model (or the Business model), and the domain model depends on the DAL. In more modern implementations, the domain model is DAL-independent; instead, the relationship is inverted, and the abstract Mapping layer is introduced later using the IoC container. In any case, each level depends only on the previous level.

In MVC architecture, C is the controller, V is the user interface (views), and M is the domain model. Therefore, MVC is a presentation architecture, not a system architecture. It does not encapsulate data access. This may not necessarily fully encapsulate the domain model, which can be considered as an external dependency. It is not multi-level.

If you want to physically separate the layers, this is usually done by displaying the domain model as a web service (i.e. WCF). This gives you improved scalability and a clearer separation of problems. The domain model is literally reusable and can be deployed on many machines, but has significant initial development costs, as well as fixed maintenance costs.

The server architecture reflects the 3-tier diagram above:

 Database Server <----- Web Services <----- Application 

An “application” is your MVC application that shares a domain model with web services (via SOAP or REST). Web services run on a dedicated server (or servers), and the database is obviously hosted on its own server. This is a three-tier architecture with 3 servers.

+6
source

In some circles, I saw this discussion as the difference between the n-tier and the n-layer, where the “layer” in this context potentially represents another machine. In order to have an intermediate level, using this definition, it must be placed. For example, if you had a service level at which a presentation layer called to get its data, then the service level might be on a different machine than the presentation or database. However, this service level is hosted either as a Windows service or as a web service. Ie, there is a process of listening for requests on this machine. Thus, you cannot just move the bin folder to another machine and hope for this to work. I would look at WCF (Windows Communication Foundation) to create these types of services.

+4
source

ASP.NET MVC does not help you in creating a 3tier system. This is really just an interface template.

The main problem that you have to solve the implementation of a multi-level system is the transfer of objects from one server to another. You should find a way to serialize all objects depending on the transport channel. It slows down and development gets complicated.

There are reasons to have a separate application server: you may have the logic that a different application is required, or the server application may have different permissions than on the web server. But it’s hard to imagine a site with high traffic, where all requests lead to a call to a remote application server.

+1
source

The next logical extension will be two web servers and one database server.

After all, after adding many web servers, it might be worth adding a service layer.

You might also want to add a distributed cache, a session state server, an email server, and other specialized servers at some point when you scale.

0
source

So your questions seem to be ...

"can you just move / bin and all applications to a separate server from view views?"

If I understand correctly, I believe that the files in the bin folder will be compiled codes for your asp.net pages. If so, then no, I believe that they should be on the same machine as the asp pages.

If you want your business logic on a separate machine to be displayed at the presentation level, you would need to wrap this code in a separate dll and set it using soap or some other protocol .. and then call these open SOAP DLLs on another server from the code in your presentation layer.

0
source

Source: https://habr.com/ru/post/1306620/


All Articles