The three-tier architecture divides the entire business application into the interface layer (User Interface layer, UIL), the business logic layer, the BLL, and the data access layer, the DAL. 1: Interface layer:mainly refers
to the interface that interacts with the user . Used to receive data entered by the user and to display the data that the user needs after processing. If the logical layer is quite powerful and complete, the logic layer can provide services perfectly, regardless of how the presentation layer is defined and changed. 2: Business Logic Layer: A bridge between the UI layer and the DAL layer . Implement business logic . Business logic includes: validation, calculations, business rules, and so on. < Span lang= "ZH-CN" > 3: Data access layer: dealing with the database ui layers. The user's needs are reflected to the interface (uiuibll,blldal< Span lang= "ZH-CN" >,dal Rule ⒈ most critical, the UI layer can only be used as a shell and cannot contain any business logic (bizlogic) processing (only a small number (or no) of SQL statements or stored procedure calls, and these statements guarantee that the data will not be modified). ⒉ should be designed from the BLL rather than the UI. The BLL layer should implement all bizlogic on the API, in an object-oriented manner (if Uilayer is removed, the project can provide all the functionality at the INTERFACE/API level). ⒊ whether the data layer is a simple sqlhelper or with mapping classes, should be a certain degree of abstraction to achieve system-independent (DAL can be ported to other similar environment projects). ⒋ regardless of whether you use COM + (Enterprise Service), or remoting, or remote object technology such as webservice, regardless of whether the deployment is really deployed to different servers, at least in the design time to do such considerations, further, It is also considered that multiple servers are clustered by load balancing (three modules, which can be run separately on different servers).Advantages
1, the structure is clear, the coupling degree is low,
2, the maintainability is high, the expansibility is high;
3, to facilitate the development of task synchronization; Easily adapt to changes in demand
Disadvantage
1, reduce the performance of the system. 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 amount of code, increase the workload
Mvc
If a framework such as an ORM (Object Relation Mapping) is a framework pattern for the data access layer, decoupling the business logic from the data, the business logic no longer cares about how the underlying data is stored and read. All the data presented to the business logic layer is a one-to-one object.
MVC is the framework pattern of the presentation layer. Used to decouple the business logic from the view. It is easy to expand and easy to test.
Active MVCMVC originates from desktop applications, and its theoretical thinking corresponds to active MVC, where the initiative means that the model will proactively notify the view update. Model is used to encapsulate data related to the business logic of the application and how to handle the data. Changes to the data in the model are generally advertised through a refresh mechanism. To implement this mechanism, the views that are used to monitor this model must be registered in advance on this model, so that the view can understand the changes that have occurred on the data model. The View view layer is responsible for the presentation of the data. There is generally no logic on the program in the view. To implement the Refresh feature on the view, the view needs to access the data model it monitors, so you should subscribe to the model's events beforehand in the data it is monitoring. Controller controllers are connectors between M and V to control the flow of applications. It handles the event and responds. An "event" includes the user's behavior and changes on the data model. Passive MVC is a process in passive MVC, unlike active MVC, where view does not subscribe to events that change the model data, waiting for the model to notify that the view needs to be updated based on the new data. In passive MVC, the controller is responsible for notifying the view that there are data changes that need to be updated. The difference between passive MVC and active MVC 1, the model is not known to view and controller, it is only used by them 2, the controller uses the views, and notifies it to update the data display 3, the view is only when the controller notifies it to the model to fetch data when it does this (the view does not subscribe to or monitor the update of the model) The MVC framework in Web applications is the passive MVC pattern in the Web, because HTTP works together based on request and response, so when the server-side model (data) changes, it does not immediately update the client view, Updates are only available when the client requests or refreshes the page. is a typical MVC framework for MVC in a request flow. MVC Benefits
Because MVC separates the view layer and the business layer nicely, it has the following advantages
- Low coupling resistance
- Fast development speed
- High maintainability
- No control concept, no encapsulation of HTML, easy to understand
- More similar to other platforms (Java, PHP). Easy access to Talent
The misconception of MVC uses the model as a solid class (entity)
In MVC, the model should contain 2 parts, part of the business logic, and part of the data that provides the view display.
It should be the real implementation layer of the business logic. So the model is actually business model. and
controller only acts as a "bridge", it is responsible for forwarding the view request to model, and then is responsible for the model processing end of the message to notify the view. The controller is used to decouple the view and model, specifically to separate the UI from the logic (the interface is separated from the code). Quoted from Http://www.techopedia.com/definition/27454/model-mvc-aspnetTechopedia explains model (MVC) The model is the part of MVC which implements the domain logic. In simple terms, this logic is used to handle the data passed between the database and the user interface (UI). The Model is known as domain object or domain entity. The domain objects is stored under the Models folder in ASP. The domain model represents the application perspective for the data to be handled whereas a view model are required to pro Duce the engine that generates the View.this definition is written in the context of the ASP. All of the business logic is placed in controller-side MVC, which encapsulates communication and easily becomes chatty's highly-coupled concentrator.
- Write business code in the controller
- People who write code are not "practicing" enough. Unable to understand cohesion-poly low-coupling OO thought theme
- The project leader is laissez faire. Cause code clutter.
The controller becomes dependent on the information data center or database, and the object is indirectly coupled by the action of the Controller
- Introduction of IOC container
Mvpartech This article about the V-p interaction problem in MVP mode the V in MVP mode represents an interface, an interface that abstracts the UI interface. interface means that any interface that implements the interface can reuse existing presenter and model code. The real sense of isolating view details and the complexity of the pattern. MVP has many variants, of which one of the most commonly used variants becomes the passive view (passive view). The relationship between passive View,model, View, and presenter is as shown. View and Modell cannot interact directly, and view deals with model through presenter. Presenter accepts the UI request for the view, completes the simple UI processing logic, calls the model for business processing, and invokes the view to reflect the corresponding results. View is directly dependent on presenter, but presenter indirectly relies on view, which is directly dependent on the interface of the view implementation. Passive view, as the name implies, view is passive. So who's taking the initiative? The answer is presenter.
The
- presenter is the control center of the entire MVP system, not simply the person who handles the view request;
- view is simply a user interaction request, and for the logic and process that responds to user interaction, view does not participate in the decision, The real decision-maker is presenter;
- view sends a user interaction request to presenter should take the tone: "I now send the user interaction request to you, you look to do, need me when I will assist you", should not be like this: " I'm working on the user interaction request now, I know what to do, but I need your support because the model that implements the business logic trusts you Only ";
- for data bound to view, it should not be" pulled "from the presenter view. Should be presenter actively "push" to view,
- view as far as possible do not maintain the data state, because it is only to achieve simple, independent UI operation; presenter is the coordinator of the whole system, It arranges the work for the view and model according to the logic that handles the interaction.
In the MVP, presenter completely separates the model from the view, and the main program logic is implemented in presenter. Furthermore, presenter is not directly related to the specific view, but interacts through a well-defined interface, allowing the presenter to be kept constant when the view is changed, that is, reuse! Not only that, we can also write Test view, simulate the user's various operations, so as to achieve the test of presenter-without the need to use automated testing tools. We can even test the logic of presenter by writing a mock Object (that is, an interface that implements the model and view, but no concrete content) when the model and view are not finished. &NBSP;&NBSP;MVP Advantage 1, the model and the view completely separate, we can modify the view without affecting the model &NBSP;2, can more efficient use of the model, because all the interaction occurs in a place--presenter internal 3, We can use a presener for multiple views without changing the logic of presenter. This feature is very useful because view changes are always more frequent than models. 4, if we put logic in the presenter, then we can test these logic (unit test) &NBSP;MVVMMVVM mode, a ViewModel and a view match, without the iview interface in the MVP, from the user interface. Instead of the full and view bindings, all changes in the view are automatically updated to ViewModel, and any changes to the ViewModel are automatically synced to the view. The reason this automatic synchronization is possible is that the properties in ViewModel implement an interface such as observable, which means that when a property's set method is used, the property modification event is triggered at the same time, so that the bound UI is automatically refreshed. (in WPF, this observable interface is inotifypropertychanged; in Knockoutjs, it is implemented by the function ko.observable () and ko.observrablecollection ()) So MVVM is a step ahead of the MVP, in the MVP, V is the interface iview, which solves the interface UI coupling; While MVVM simply integrates seamlessly with ViewModel and UI, ViewModel directly represents the UI. But MVVM does this by relying on specific platforms and technologies, such as WPF and Knockoutjs, which is why vieWmodel does not need to implement interfaces because, in essence, the use of the MVVM pattern for specific platforms and technologies is a platform that cannot replace the UI. The proposed MVVM originates from WPF, primarily for separating the application interface layer and the business logic layer. Wpf/siverlight is based on data-driven development. In the MVC and MVP model, the view layer has a lot of code logic, the developer of the view layer is the programmer, although the Ui/ue team will do a lot of work, but the "implementation" of this layer is still a programmer. In the development of WPF developer of the view layer of the display is not enough, although the art is very good, but he will say "Unfortunately I do not program." So, we need a way to extract the code logic from the view layer, and the view layer is purely for the artist to build it. Accordingly, You need to extract the corresponding logic from the view layer to a code layer so that the programmer can focus on it. &NBSP;&NBSP;MVC, MVP and MVVM pattern usage summary because in WinForm, it is not possible to support bidirectional binding of data and interfaces and monitoring of events as WPF does, so MVP is the best choice in WinForm. Using knockout in WPF and HTML interfaces, observable is implemented, so use MVVM. (It should be said that WPF is designed for use with MVVM) in Web applications, because HTTP works in a request-and-response manner and cannot remain connected. So MVC is the best choice when it's impossible to get the message passing between presenter in the MVP and the ViewModel and interface in MVVM. &NBSP;MVC is more tolerant than MVVM and MVP, and in the MVC v layer, you can further include the implementation of MVVM or MVP, while the C layer can also use MVP (V is the output data) to further cut the flow and output of the data, the M layer can be similar to the MVVM architecture, when V ( component), the VM can automatically detect and update the model (database) when there is a profile. The significance of the introduction of MVVM in &NBSP;MVC front-end engineers have a real separation from program developers, and of course, in order to reduce the amount of repetitive code, it is necessary for front-end personnel to understand a database structure. eg:augularjs
Three-tier architecture, MVC
