Orm,dao,mvc,pojo

1.ORM

Object Relational Mapping (relational Mapping, or ORM) is a technique to solve the mismatch between object-oriented and relational databases. In a nutshell, ORM automatically persists objects in a Java program to a relational database by using metadata that describes the mapping between the object and the database. Essentially, it's converting data from one form to another. This also implies additional execution overhead, however, if ORM is implemented as a middleware, there are many opportunities for optimizations that do not exist in the handwritten persistence layer. More importantly, the metadata needed to control the transformation needs to be provided and managed, but again, this is less expensive than maintaining handwriting, and even an object database that adheres to the ODMG specification still requires class-level metadata.

Object-Relational mapping (Object/relation Mapping, or ORM) is a result of the development of object-oriented software development methods. The object-oriented development method is the mainstream development method in the enterprise application development environment, and the relational database is the mainstream data storage system which is stored permanently in the enterprise-level application environment. object and relational data are two representations of business entities, and business entities behave as objects in memory and behave as relational data in the database. There are associations and inheritance relationships between objects in memory, and in a database, relational data cannot directly express many-to-many associations and inheritance relationships. Therefore, object-relational mapping (ORM) system usually exists in the form of middleware, which mainly realizes the mapping of program object to relational database data.

Object-oriented is developed from the basic Principles of software engineering (such as coupling, aggregation, encapsulation), and the relational database is developed from the mathematical theory, and the two sets of theories have significant differences. In order to solve this mismatch, object-relational mapping technology emerged.

Let's start with the O/R. The letter O originates from "object", and R is derived from "relationship" (relational). In almost all programs, there are objects and relational databases. In the business logic layer and the user interface layer, we are object-oriented. When the object information changes, we need to keep the object's information in the relational database.

When you develop an application (do not use O/R Mapping), you may write a lot of data access layer code to save, delete, read object information from the database, and so on. You wrote a lot of ways to read object data, change state objects, and so on in DAO. And the code is always repeating itself.

If you open your recent program and look at the DAO code, you will certainly see a lot of approximate generic patterns. As an example of how to save an object, you pass in an object, add SqlParameter to the SqlCommand object, correspond all the properties and objects, set the CommandText property of the SqlCommand to the stored procedure, and then run SqlCommand. Write the code repeatedly for each object.

Besides, is there a better way? There, introduce a O/R Mapping. Essentially, an O/R mapping will generate DAO for you. Instead of writing the DAO code yourself, use the O/R Mapping. You use O/R mapping to save, delete, read objects, O/R mapping is responsible for generating SQL, you just need to care about the object just fine.

Object Relational mapping is successfully applied in different object-oriented persistence layer products, such as TORQUE,OJB,HIBERNATE,TOPLINK,CASTORJDO, TJDO and so on.

The general ORM consists of the following four parts:

An API for CRUD operations on persistent class objects;

A language or API used to specify queries related to class and class attributes;

A tool that prescribes mapping metadata;

One technique allows ORM implementations to dirty checking with transactional objects, lazy association fetching, and other optimizations.

2.DAO

DAO (data Access Object) is an application programming interface (API) that exists in Microsoft Visual Basic, which allows programmers to request access to Microsoft's Access database. DAO is Microsoft's first object-oriented database interface. The DAO object encloses the Jet function of access. With the Jet function, it can also access other Structured Query Language (SQL) databases.

The Java EE developer uses the data Access object (DAO) design pattern to separate the underlying data access logic from the high-level business logic. Implementing the DAO pattern can be more focused on writing data access code.

Let's review the DAO design pattern and the data Access object first.

DAO Foundation

DAO mode is one of the standard Java EE design patterns. Developers use this pattern to separate the underlying data access operations from the business logic on top. A typical DAO implementation has the following components:

1. A DAO factory class;

2. a DAO interface;

3. A specific class that implements the DAO interface;

4. Data passing objects (sometimes called value objects).

The specific DAO class contains the logic to access data from a specific data source. In this section, you will learn the techniques for designing and implementing data Access objects.

Transaction partitioning:

One important thing to remember about DAO is that they are transactional objects. Each action that is performed by the DAO (object creation, update, or delete data) is associated with the transaction. Similarly, the concept of transaction partitioning (transaction demarcation) is particularly important.

A transaction partition is a way of defining the definition of a transaction. The Java EE specification describes two patterns for transactional partitioning: Programmatic transactions (programmatic) and declarative transactions (declarative). The following table is a split between the two modes:

Declarative transactional partitioning of programmatic transactions

Programmers use the EJB's deployment descriptor to declare transactional properties The programmer assumes responsibility for writing transaction logic code.

The run-time environment (the EJB container) uses these properties to come from a managed transaction. The application controls transactions through an API interface.

3.MVC

MVC-an MVC design idea

MVC English is Model-view-controller, that is, an application of input, processing, output process according to model, view, Controller to separate the way, such an application is divided into three layers-model layer, view layer, control layer.

View

The view represents the user interface, which can be generalized as an HTML interface for Web applications, but it can be XHTML, XML, and applets. With the complexity and scale of the application, the processing of the interface becomes challenging. An application may have many different views, the MVC design pattern is limited to the processing of the view's data collection and processing, and the user's request, not including the business process on the view. The processing of business processes is delivered to the model. For example, an order view only accepts data from the model and is displayed to the user, as well as passing input data and requests from the user interface to the control and model.

Model

Model: The processing of business processes/States and the development of business rules. The processing of business processes is a black box for other layers, the model accepts the data requested by the view, and returns the final processing result. The design of the business model can be said to be the main core of MVC. The current popular EJB model is a typical application example, it makes a further division of the model from the angle of application technology implementation, in order to make full use of the existing components, but it cannot be used as the framework of application design model. It simply tells you that you can use some of the technical components as a result of this model, which reduces technical difficulties. For a developer, you can focus on the design of the business model. The MVC design pattern tells us that the application model is extracted according to certain rules, and the level of abstraction is very important, which is also the design basis to judge whether the developers are excellent. Abstract and concrete cannot be too far apart, nor too close. MVC does not provide a design approach to the model, but only tells you that you should organize and manage these models to facilitate the refactoring of the model and improve reusability. We can use object programming to make metaphors, and MVC defines a top-level class that tells its subclasses that you can only do this, but there's no limit to what you can do. This is important for developers of programming.

The business model also has a very important model that is the data model. The data model mainly refers to the data preservation (persistence) of the entity object. For example, save an order to a database and get an order from a database. We can list this model separately, and all operations on the database are limited to that model.

Control

The control (Controller) can be understood as receiving requests from the user, matching the model to the view, and collectively completing the user's request. The function of dividing the control layer is also obvious, it clearly tells you that it is a dispatcher, choose what kind of model, choose what kind of view, what kind of user request can be completed. The control layer does not do any data processing. For example, when a user clicks on a connection, the control layer accepts the request and does not process the business information, it only passes the user's information to the model, tells the model what to do, and selects the view that meets the requirements to return to the user. Therefore, a model may correspond to multiple views, and one view may correspond to multiple models.

The separation of models, views, and controllers allows a model to have multiple display views. If a user changes the model's data through a view's controller, all other views that depend on the data should be reflected in these changes. Therefore, whenever any data changes occur, the controller notifies all views of the change, causing the updates to be displayed. This is actually a model of the change-propagation mechanism. The relationships between models, views, and controllers, and their main functions, are shown in 1.

MVC-Two, the implementation of MVC design pattern

Asp. NET provides a similar environment for implementing this classic design pattern. The developer implements the view by developing the user interface in the ASPX page, the function of the controller is implemented in the logical function code (. cs), and the model usually corresponds to the business part of the application system. The implementation of this design in ASP. A multilayer system, which has obvious advantages over the system of the classic ASP architecture. The user display (view) is separated from the action (Controller), which improves the reusability of the code. Separating the data (model) from the Action (Controller) of its operation allows you to design a system that is independent of the data stored in the background. As far as the nature of MVC structure is concerned, it is a method to solve the problem of coupling system.

2.1 views

A view is a representation of a model that provides a user interface. With multiple user parts that contain a single display page, a complex web page can show content from multiple data sources, and the Web page staff, artists, can participate in the development and maintenance of these web pages alone.

Under ASP. NET, the implementation of the view is simple. Page development can be done directly in the integrated development environment by dragging controls, just as you would develop the Windows interface. Each page is described in the form of a composite view: A page consists of multiple sub-views (user parts); A child view can be a Web custom control that is nested within the simplest HTML control, server control, or multiple controls. The page is defined by the template, the template defines the layout of the page, the label and number of user parts, the user specifies a template, and the platform automatically creates the page based on that information. For static template content, such as site navigation on the page, menu, friendly links, these use the default template content configuration, for dynamic template content (mainly business content), because the user's request is different, can only use late binding, and for the user's different, the user part of the display content filtering. It enhances reusability and prototypes the layout of the site using a combination of pages that are composed of user parts based on the template configuration.

The general process of the View section is as follows: first, the page template defines the layout of the page, the page profile defines the specific contents of the view label (the user part), and the page layout policy class initializes and loads the pages, each user part initializes according to its own configuration, loads the validator and sets the parameters, As well as the delegate of the event; After the user submits, through the validation of the presentation layer, the user part automatically submits the data to the business entity as the model.

This part mainly defines the Web page base class pagebase, the page layout policy class pagelayout, completes the page layout, is used to load the user part to the page, the user part base class Usercontrolbase namely the user part frame, is used for the dynamic loading inspection part, and personalization of user parts. In order to achieve the flexibility of Web applications, the View section also uses a number of configuration files such as: template configuration, page configuration, path configuration, authentication configuration, and so on.

2.2 Controller

To be able to control and coordinate the processing of each user across multiple requests, the control mechanism should be managed in a centralized manner. Therefore, the controller is introduced in order to achieve the purpose of centralized management. The application's controller set receives the request from the client (typically a user running the browser), decides what business logic functions to perform, and then delegates responsibility for the next user interface to an appropriate view component.

The controller provides a centralized entry point for controlling and processing requests, which is responsible for receiving, intercepting, and processing user requests, and delegating the request to the Distributor class, which determines the view that is presented to the customer based on the current state and the results of the business operation. In this section, we mainly define the Httpreqdispatcher (Distributor Class), the Httpcapture (request-capturing class), the controller (Director Class), and so on, and they cooperate with each other to complete the functions of the controller. The request capture class captures the HTTP request and forwards it to the Controller class. The Controller class is the initial entry point for all requests that are processed in the system. The controller completes some necessary processing to delegate the request to the Distributor class, and the Distributor class Distributor is responsible for the management and navigation of the view, which manages which view will be selected for the user and is provided to the distribution resource control. In this section, the Distributor, strategy, factory method, adapter and other design patterns are adopted respectively.

To enable the request-capture class to automatically capture user requests and process them, ASP. NET provides a low-level request/response API that enables developers to service incoming HTTP requests using the. NET Framework class. To do this, you must author a class that supports the System.Web.IHTTPHandler interface and implement the ProcessRequest () method, that is, the request-grabber class, and add the class in the section of Web. config. Each incoming HTTP request that ASP. NET receives is ultimately handled by a specific instance of the class that implements IHttpHandler. IHttpHandlerFactory provides a structure that handles the actual parsing of IHttpHandler instance URL requests. HTTP handlers and factories are declared as part of the Web. config file in the ASP. ASP. NET defines a configuration section in which handlers and factories can be added and removed. Subdirectories inherit the settings of Httphandlerfactory and HttpHandler. HTTP handlers and factories are the principals of the ASP. The factory assigns each request to a handler, which processes the request. For example, in a global machine.config file, ASP. NET will map all requests to the ASPx file to the Httpcapture class:

...
...

2.3 Models

The models in the MVC system can be divided into two categories-the internal state of the system and the action of changing the state of the system. The model is where all of your business logic code snippets are located. This article provides a business entity object and a business processing object for the model: All business processing objects are subclasses derived from the Processbase class. The business processing object encapsulates the specific processing logic, invokes the business logic model, and submits the response to the appropriate view component to produce a response. Business entity objects can describe client form data by defining attributes. All business entity objects are entitybase derived subclass objects, and the business processing object can read and write directly to it without the need to interact with the request, response object for data. Support for interaction between views and models is achieved through business entity objects. When implemented, separate the "What to Do" (Business processing) and "How to" (Business entities). This enables the reuse of business logic. Because the specific business of each application is different, its specific code instances are no longer listed here.

4.POJO

POJO (Plain ordinary Java object) Simple Java objects, actually is the ordinary JavaBeans, is to avoid and EJB confusion created by the abbreviation.

The Pojo name is used to avoid confusion with EJBS, and the abbreviation is more straightforward. There are classes of properties and their getter setter methods, there is no business logic and can sometimes be used as VO (value-object) or DTO (Data Transform object). Of course, if you have a simple arithmetic attribute is also possible, However, there are no business methods, nor can we carry methods such as connection.

Orm,dao,mvc,pojo