Difference between mvc and three-tier architecture

First of all,MVC and three-tier architecture, are not the same.

Three-tier architecture, DAL (Data Access Layer), BLL (Business Logic Layer), and WEB Layer have their own roles, which is meant to be separation of duties.

MVC is Model-View-Controller, strictly speaking, these three add up to the WEB layer in the three-tier architecture, that is to say, MVC to the three-tier architecture of the WEB layer once again for the differentiation, divided into the controller, view, entity, the three parts of the controller to complete the page logic, through the entity to complete the call with the interface layer; and the C-layer direct talk to the BLL in the three layers.

So, there is no concept of action in the three-tier structure of .net.

asp.net mvc is a newly released web development architecture from Microsoft. In order to solve the traditional asp.net development can not be separated Model, View and Controller and design.

Ordinary website in order to solve the problem of portability, maintainability, scalability, etc., the site will be designed into three independent modules , Model is responsible for the database part , View is responsible for the interface of the web page , and Controller is responsible for the interface and the interaction of data and business logic , so that the design of the site if you want to design or re-development of a certain module of the other modules are not This design of the site if you want to design or redevelop a module on the other modules are not affected. However, asp.net page background code and each page code are one-to-one correspondence, business logic in some cases inevitably be written to the background code associated with the View. This does not ensure the separation of View and Controller , it is also difficult to realize the site rewrite and upgrade .

In MVC, the page code is not a one-to-one correspondence with the background code, but were stored into the Controller and View two parts, completely solved, View and Controller can not be independent of the problem. This improves the process of rewriting and upgrading the site.

But MVC also has its drawbacks, because in the page code can no longer use the server control, so the use of some asp.net server-side controls has brought trouble, and MVC also brings a lot of obstacles to the design of the page.

ASP.NET MVC is a new web development architecture released by Microsoft in April 2009, /en-us/library/dd394709.aspx, which is the traditional sense of MVC development ideas into the ASP.NET development.

So let me also talk about my understanding of the two.

First of all, there is a problem with the topic itself: the difference between "XX structure" and "XX pattern"? What is the difference between the Chinese social system and the American way of life?

The two themselves are different directions and perspectives of the problem, in the practical application of their actual existence of some similar features, in many books have not been in-depth explanation, so as to cause confusion, in order to better understand them, let's say the difference.

First of all, the N-tier structure is a software abstraction hierarchy, a vertical cut of complex software, each level to complete the same type of operation, so that the various codes to complete the mission as the basis for partitioning, in order to lower the complexity of the software, to improve its maintainability. Generally speaking, there is a downward dependency between the levels, and the upper level code cannot be developed until the lower level code determines its interface (contract), and changes in the interface (contract) of the lower level code will cause the upper level code to change together. The three-tier structure is a kind of N-tier structure, which is a kind of N-tier structure with a wide range of applications that has been widely used by people for a long time, and has been widely spread as a typical software hierarchy and even written into textbooks.

The MVC pattern is a composite design pattern, a solution that can be practiced over and over again to solve a real problem on a specific occasion. Coincidentally, he also has three things, so people have a taken-for-granted correspondence: display layer - View; business logic layer - Control; persistence layer - Model. first of all, there is no obvious hierarchical structure between the three things in MVC, there is no obvious downward dependency, on the contrary, View and Model is often more independent, and Control is the bridge between the two, they are more like horizontal cuts. In this way there is a result , MVC each block can be tested independently , while the three-tier structure , the upper module of the runtime test is bound to provide the lower code or provide the same interface to the pile . Relatively speaking, MVC is much more complex, but the structure is clearer and less coupled.

Additionally, every piece of MVC internals, especially Model internals, are often designed to be multi-layered. In my opinion a good MVC pattern built structure , Control is the core , small and more stable , can be provided as a core framework , there are extension points , but basically can be simply configured without any code to run . View may be a set or a variety of optional view engine, determines the software to display the interface for the use of the use of the main workload lies in the expansion point and according to the need for a different number of view templates.Model is the business provider, determines the functionality provided by the software, and its internal may be a number of common classes or the implementation of certain interfaces, in this piece of the business may be based on different and colorful. Different and colorful, for complex software may be divided into many layers, such as business logic layer, business provider layer, system provider layer, data provider layer, data access layer and so on.

I often use the analogy of MVC as an example of the kind of cassette game consoles that I used to play as a child, Control is the mainframe, in general I buy a mainframe on the line, as long as he does not break down, he has been able to let me play this kind of game. view is the TV and gamepad, the TV can work independently, he does not care about the input is a TV signal, DVD player signals or game signal, he just display, and he only cared about the display, and he is the only way to get the signal. He only cares about the display, and he decides how we see the effect, if I want a larger size or colorful display, I just need to buy a corresponding TV on the line, the handle can also be changed, to remote stick or with vibration. And the manufacturer of the console and TV never knows what kind of game might be running on it. Cassettes may have game code and memory cells in them, all designed to fit the game.

Some people have mentioned interfaces to cassette slots provided by the game console, and in design, sometimes a set of interfaces are also provided by the Control for Model or View implementation, which creates a dependency. Generally speaking there is not much problem with this design, it just raises the coupling between modules and brings some intrusiveness. In order to be more perfect, instead of using interfaces to provide contracts, you can use configuration information (or metadata information) + reflection to provide contracts, then this class interface can be degraded to as long as it conforms to the CLS, that is, the ordinary class, just like nowadays, computer interfaces are widely used USB, whether it is a USB flash drive, a printer, a scanner, or a dongle, they are all just ordinary USB devices.

When it comes to USB, there is an off-topic, pluggable design of the module or even hot-pluggable design, the system can dynamically mount or remove the module without stopping the operation of the system, dynamically mount the module requires the system to be able to automatically discover the new module and auto-configure it according to the self-description of the information removed may be a little more complicated, need to "securely remove the hardware

In the case of a design, it is possible to use a "safe hardware deletion" feature.

When designing a framework for extensive reuse, you will consider a variety of scenarios to achieve a greater degree of adaptability, and the MVC pattern can be applied more casually in general projects.