"Go" mvc

I also see someone asking about the three-tier architecture and the MVC relationship, which is a bit of a dogma. Because they all logically put the application into three blocks, rounding up a number 3, someone has to link them together.

These two things I touch for several years, have a little experience, Express:

Layer three is layer three, MVC is MVC, they have nothing to do with it.

layer Three is a layer of three from the perspective of the entire application architecture (and can be layered if the program requires it).

Layer three is designed to solve the problem of code encapsulation at different stages of a business operation throughout the application, in order to enable programmers to focus on the business logic at a particular stage.

For example, the database operation code is encapsulated in a layer, providing some methods to directly return the corresponding data according to the parameters of the user, so that when dealing with the specific business logic, there is no need to care about the data storage problem.

MVC is a few modules of different functions that are divided in the view layer of the application (BS structure).

MVC is mainly to solve the application user interface style substitution problem, the Display data HTML page as far as possible and business code separation. MVC separates the Pure Interface presentation logic (user interface) into some files (views), puts some program logic (Controller) that interacts with the user in a few files, passes the data in views and controllers and uses some entity objects that specifically encapsulate the data. These objects, collectively referred to as models.

Only so MVC has nothing to do with layer three because they use different scopes: three layers can be applied to any language, any technology application, and MVC is just to solve the coupling of the parts of the BS application View layer. They are non-conflicting, can exist at the same time, and can be used depending on the situation.

Three-tier architecture is mvc!

At first, the teacher always said three layer Mvc,mvc three layer architecture ...

So the beginning of the brain is a concept: Layer three is Mvc,mvc is a three-tier architecture. And it's reasonable to think about it, it's all "three". MVC is a three-letter, three-tier architecture is also "three", and rightly so on the corresponding. And then it's been "wrong" for a long time.

The three-tier architecture is by no means mvc!!

After studying the Java EE, I found that the teacher said that it seems wrong, MVC and three-tier architecture is not a thing. The three-tier architecture is composed of the interface layer (UI) business Logic Layer (BLL) and the data Access Layer (DAL), which is composed of the model layer (M) interface layer (View) and the control layer (Controller), and they do not correspond to each other.

If it is hard to give them a match, then the UI in the three-tier architecture corresponds to the view (JSP) in MVC, which is used to display and get the data for the interface. The BLL layer and the DAL layer in the three-tier architecture correspond to the model (JavaBean) layer in MVC, which is used to process the data passed from the upper layer and the data obtained from the database; the controller (Servlet) in MVC is part of the UI in the three-tier architecture, What we often talk about is the servlet.

As shown in the following:

Suddenly feel the world is clear, on the stratification and in-depth understanding of a step.

In fact, three-tier architecture and MVC is still a thing!!!

The last few days have been thinking about what is the relationship between the three-tier architecture and MVC, and why did the teacher put it together at first? Then suddenly realize: in fact, three layer architecture and MVC is the same!!! What we see is not the same as it is on the surface. The core thing is the same, then what is the core?

Answer Yue: layering, decoupling!

If you look at the three-tier architecture and MVC in terms of decoupling, they are consistent, but the partitioning method is different, as shown in the figure above. From this point they can be said to be a thing. This is equivalent to the way we see steamed buns and noodles, on the surface they are not the same (note only the surface) but their core is consistent, are face ...

The learning process of knowledge will be like the old cow chewing, need to continue to deepen the understanding, in the end to truly understand

The understanding of things from perceptual to rational, is a step by step deepening, each step of deepening may overturn the former self, may be more agree with the former self. If it is to overthrow the former self, then the understanding of this thing has happened to change the world, but if the approval of the previous self also does not mean that their views have not changed, often seemingly consistent on the surface of something actually the kernel and must be the same. Just like when I first thought that the three-tier architecture and MVC were a thing to the end and that the two were a thing, but the level of understanding was definitely different.

As for the future will not be overturned their views I do not know, can only say that each overthrow represents progress, represents a deeper understanding of the layer, so I look forward to the next rejection of their own.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////

three-layer schema editing

The three-tier architecture (3-tier architecture) typically has a three-tier architecture that divides the entire business application into: the interface layer (User Interface layer), the business logic layer, the data access layer Access layer). The purpose of distinguishing hierarchy is to think of "high cohesion and low coupling". In the design of software architecture, layered structure is the most common and most important structure. Microsoft's recommended layered structure is generally divided into three tiers, from bottom to top: The data access layer, the business logic layer (or also called the domain layer), the presentation layer.

Chinese name

Three-tier architecture

Foreign names

3-tier Architecture

Classification

interface layer, business logic layer, data access layer

eye     

"high cohesion, low coupling" thought

excellent      point

reduced dependency normalization between layers and layers

system architecture is complex and not suitable for small projects

Three-layer Structural principle editor  3 hierarchy, the main functions and business logic of the system are processed in the business logic layer. The so-called three-tier architecture is the addition of a "middle tier", also called a component layer, between the client and the database. Here the three-layer system, not refers to the physical three layer, not simply placed three machines is three-layer architecture, also not only B/s application is the three-tier architecture, three layer refers to the logic of the three layer, that is, the three layers placed on a machine. The three-tier application puts business rules, data access, legitimacy checks, etc. into the middle tier for processing. Typically, the client does not interact directly with the database, but instead establishes a connection with the middle tier through com/dcom communication, and then interacts with the database through the middle tier. The role of each layer Edit 1: The data access layer: mainly for non-raw data (database or text files, such as the form of data storage) operation layer, rather than the original data, that is, the operation of the database, rather than the data, specifically for the business logic layer or presentation layer to provide data services. 2: Business logic Layer: mainly for the specific problem of operation, can also be understood as the operation of the data layer, the data business logic processing, if the data layer is a building block, the logic layer is the building of these blocks. 3: The interface layer: The main means of the web, can also be expressed as a WinForm way, the web can also be represented as: ASPX, if the logical layer is quite powerful and perfect, no matter how the presentation layer is defined and changed, the logic layer can provide services perfectly. Distinction method Edit 1: Data Access layer: The main view of the data layer contains no logical processing, in fact, its various functions mainly to complete the operation of the data files. Without having to worry about other operations. 2: Business Logic Layer: mainly responsible for the operation of the data layer. In other words, the operation of some data layers is combined. 3: Presentation layer: The primary request is accepted by the user, and the data is returned, providing the client with access to the application. The presentation layer is at the outermost (topmost) level, closest to the user. Used to display data and receive user input data, to provide users with an interactive interface. Business Logic Layer The business logic layer is undoubtedly the part of the system architecture that embodies the core value. Its focus is mainly on the development of business rules, the implementation of business processes and other business requirements related to the system design, that is, it is related to the domain of the system (domain) logic, and many times, the business logic layer is also called the domain layer. For example, Martin Fowler, in the book Patterns of Enterprise application Architecture, divides the entire architecture into three main layers: the presentation layer, the domain layer, and the data source layer. As a pioneer in domain-driven design, Eric Evans has made a more detailed division of the business Logic layer, subdivided into application and domain layers, and furtherThe application logic is decoupled from the solution of the domain logic. The position of the business logic layer in the architecture is critical, it is in the middle of the data access layer and the presentation layer, which plays the role of connecting link in the data exchange. Since the layer is a weakly coupled structure, the dependencies between layers and layers are downward, and the bottom layer is "ignorant" to the upper layer, and changing the upper-level design has no effect on the bottom of its invocation. If you follow the idea of interface-oriented design in a layered design, this downward dependency should also be a weak dependency. Therefore, without changing the definition of the interface, the ideal layered architecture should be a "drawer" architecture which can be extracted and replaceable. Because of this, the design of the business logic layer is especially critical for a scalable architecture, because it plays two different roles. For the data access layer, it is the caller and, for the presentation layer, it is the callee. Dependency and dependent relationships are entangled in the business logic layer, and how to implement the decoupling of dependencies is a task left to the designer in addition to implementing business logic. Data-tier data access layer: sometimes referred to as a persistent layer, it is primarily responsible for database access, access to database systems, binary files, text documents, or XML documents. The simple argument is to implement the select,insert,update,delete of the data table. If you want to add an ORM element, it will include the mapping between the object and the data table, and the persistence of the object entity. Rules to edit the three-tier structure of the program is not said to divide the project into Dal,bll,webui three modules called three layers, the following questions in your project: ⒈uilayer There are only a few (or no) SQL statements or stored procedure calls, and these statements guarantee that the data will not be modified? ⒉ If you take uilayer off, will your project provide all the functionality on the INTERFACE/API level? ⒊ can your dal be ported to other projects of similar environment? ⒋ three modules can be run on separate servers? If not all of the answers are Yes, Then your project is not a strictly three-tier program. The three-tier program has some rules that need to be agreed upon: ⒈ most critical, the UI layer can only be used as a shell and cannot contain any business logic (bizlogic) processing ⒉ design should start from the BLL rather than the UI. The BLL layer should implement all bizlogic in the API, in an object-oriented manner ⒊ regardless of whether the data layer is a simple sqlhelper, or with mapping over the classes, should be in a certain degree of abstraction to achieve system-independent ⒋ regardless of the use of COM + ( Enterprise Service), or remoting, or remote object technology such as webservice, regardless of whether the deployment is actually deployed separatelyTo different servers, at least in the design of the time to do such considerations, farther, but also to consider multiple servers through load balancing for the cluster so consider whether a project should be applied to the three layer/multilayer design, first have to consider whether it is really necessary? In fact, most programs open a webapplication is enough, there is absolutely no need to do so complex. Multi-layered structures are designed to address the needs of truly complex projects. Pros and cons Editing advantages 1, the developer can only focus on the entire structure of one of the layers, 2, can easily replace the implementation of the original level with the new implementation, 3, can reduce the dependence between layer and layer, 4, conducive to standardization, 5, conducive to the reuse of the logic of each layer. 6, the structure is more clear 7, in the late maintenance time, greatly reduces the maintenance cost and maintenance time disadvantage 1, reduces the system performance. This is self-evident. Without a tiered structure, many businesses can access the database directly to get the data, and now they have to do it through the middle tier. 2. Sometimes cascade changes are caused. This kind of modification is especially reflected in the top-down direction. If you need to add a feature in the presentation layer to ensure that the design conforms to the layered structure, you may need to add code to the appropriate business logic layer and the data access layer. 3, increase the development cost. Differences with MVC edit MVC (Model model-view view-controller controllers) is an architectural pattern that you can use to create a distinction between domain objects and UI presentation layer objects. The same architecture level, the same thing is that they all have a presentation layer, but they are different in the other two layers. The concept of a controller is not defined in the three-tier architecture. This is the most different place. and MVC does not consider the logical access of the business as two layers, which is the main difference between a three-tier architecture or an MVC build program. Of course. The model is also mentioned in layer three, but the concept of model in the three-tier architecture is not the same as the concept of model in MVC, and the typical model layer in the "three layer" is made up of entity classes, while MVC is composed of business logic and access data.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////

The difference between MVC and MVC (model model-view view-controller controllers) is a design pattern that we can use to create a distinction between a domain object and a UI presentation layer object.
The same architecture level, the same thing is that they all have a presentation layer, but they are different in the other two layers.
The concept of a controller is not defined in the three-tier architecture. This is the most different place I think. and MVC does not consider the logical access of the business as two layers, which is the main difference between a three-tier architecture or an MVC build program. Of course. The model is also mentioned in layer three, but the concept of model in the three-tier architecture is not the same as the concept of model in MVC, and the typical model layer in the "three layer" is made up of entity classes, while MVC is composed of business logic and access data.

Of course, you have to understand the differences and linkages between the MVC three-tier architecture:

The three-tier architecture is the most basic project layering result, and MVC is a variant of the three-tier architecture, and MVC is a good development model. First, you need to understand what MVC means, respectively.
M, model layer, is responsible for the interaction of the business logic and the database.
V is the view layer, which is used primarily to display data and submit data
C is the controller, which is used primarily as a capture request and controls request forwarding

Layer three: UI interface layer BLL business logic layer, DAL data access layer, Model entity layer
The M in MVC is not the Model (entity layer) in the three layer, he actually includes the three layers of the Bll,dal,model, which is very important to note, which is the key to the difference between them

It is a bit like this:
Low coupling resistance
Highly reusable and adaptable
Lower life-cycle costs
Rapid deployment
Maintainability
Facilitates the management of software engineering

Of course, the advantages also have shortcomings, that is, the internal structure is complex, not easy to understand, the number of documents, management difficulty naturally also big

MVC design Pattern ...
Three-tier architecture ...
They are subdivided to get: View (UI), BIZ (BLL), DAO (DAL), Entity (Model), Controller
MVC, which unifies the BIZ (BLL), DAO (DAL), model (Entity), is called the model, and gets: View, Controller, models
Layer three in my use has not realized the existence of the controller, is completely: UI, DAO, BLL

They have the same design philosophy: Separating the view design from data persistence, which reduces coupling, is easy to scale, and improves team development efficiency.

Layer three is based on the business logic, and MVC is based on the page to divide
There is no comparability at all.
Actually, I feel good with both of them.

The MVC pattern is a composite design pattern, a solution
Layer three is a software architecture that enables programming via interfaces
Three-tier mode is an architectural pattern, and MVC is a design pattern
Layer three mode is also attributed to deployment mode, MVC can be attributed to presentation mode

Similarities and differences between MVC and the three-tier architecture

At the same architecture level, what are the similarities and differences? This article discusses their similarities and differences. Hope to help readers understand the mystery. :)

In fact, they all have a presentation layer.

But they are different in the other two layers.

Let's first explain MVC. V is view. Is the meaning of views. C is controler. Is the controller's meaning. and M is the model, the meaning of the models. These three. The most difficult to understand is the model. What is model, and why it is called model. Let me not say why the model, first explain controler.

Controller is the meaning of controllers, the so-called controller, is to forward the user request to the model layer, after processing the results back to the interface to show an intermediate layer, then controler exactly what the work of the tube? Let's not talk about it first. In the Java Web, the general definition of these three layers, generally in the Java Web, JSP acts as a v,servlet to act as C,javabean, where the servlet tube what work? Accept the input, go to the model layer to process, the processing results are saved and forwarded to the JSP, and then show the data. So its function is the basic function of the controller, it is the tube forwarding, between the V and M.

In other words, M, model, in the Java Web is said to be javabean, I know a lot of people who mistook JavaBean as an entity class, in fact JavaBean has a richer definition than the entity class, in the JavaBean in addition to its properties and fields, there can be behavior and its events , JavaBean can be understood as plain Java objects. Java generic objects, which are all objects that conform to the Java specification, are completely different from entity classes. So, I think in MVC. Business logic and data access should be placed on the model layer, that is, V is responsible for presenting the data, controler not doing business logic except forwarding. Real logical transactions, data access, and even algorithms are put into the model.

Let's talk about the three-tier architecture. Three layers in fact very good understanding, interface, business, data access, on these three, literally can understand their meaning. What I'm talking about is the difference between it and MVC. The concept of controler is not defined in the three-tier architecture. This is the most different place I think. and MVC does not consider the logical access of the business as two layers, which is the main difference between a three-tier architecture or an MVC build program.

Of course. The model is also mentioned in layer three, but the concept of model in the three-tier architecture is not the same as the concept of model in MVC, and the typical model layer in the "three layer" is made up of entity classes, while MVC is composed of business logic and access data. Not the same concept. Although the name is the same.

"Go" mvc