First, model
First of all, model is the M in MVC, that is, models. It refers to the operation of reading data and altering the data, which is closely related to the business logic. For example, a simple function, "add students to the team", it can be understood as a data processing process, it exposes an interface, the outside of the data do not need to know how to implement the interface, do not need to know its different performance under the various databases, we just need to know the model layer exposed interface can be.
Second, Dal and DAO
If we write the SQL code directly in the model, then when the business logic changes, we need the developer to rewrite the SQL statement so that we can pull this layer out of the so-called data access layer, which is usually what we call the DAL. where the Dal is the shortcut to the database access layer, which is the "DB Access Tier", it is a concept, it can also be understood as a scenario, it does not specify a specific implementation, it is this layer collectively.
The advantage of this design is that our business logic does not need to invoke the implementation of a specific data access layer, that is, our interfaces are immutable regardless of how our business logic changes. The main advantages of using the DAL are: ① developers can focus on the implementation of a layer in a structure. ② we can easily replace the implementation of the original level with the new implementation. ③ reduces the coupling between layers and layers. ④ is conducive to standardization. ⑤ facilitates the reuse of all layers of logic.
DAO is an implementation of the DAL, and the idea is that we encapsulate the access to the data source in a common API, that is, we create an interface that defines all the transactional methods that will be used in this application. The DAO is a shorthand for database access object, which is called the "accessing objects", which is generally understood to be an object-oriented way to access the database.
When we need to modify the business logic, we call these DAO classes directly, which includes a lot of code to access the database and the addition and deletion of the data, they can return the data, and we do not have to write the code in the business logic layer.
third, ORM and AR
The first thing to say is that ORM is also a encapsulation of database access, but ORM and DAO are not the same, but rather, it emphasizes that the system should be hierarchical, it is like a tool, and has a very mature product. The advantage of this is that we can automatically convert the data objects in our program into the corresponding tables and columns in the relational database, and the reference relationship between the data objects can be transformed into the connection operation between the tables through the corresponding tools.
With ORM, we can almost not write any SQL statements, create a table, declare a class, and then we just need to interact with the instance of this class, and as for how the data in this object is manipulated, we usually don't care about it, and this framework generally helps us get it done.
AR is an ORM pattern, which accompanies the Ror fire, which is responsible for integrating the persisted code into the data object, which means that the data object knows how to persist itself into the database. What distinguishes it from the traditional ORM is that the traditional ORM separates the data object from the code that is responsible for persistence, and that the data object is simply a structure containing data that is passed between the model layer and the ORM layer.
In AR, the model layer itself inherits the function of ORM, which represent the entity, also contains the business logic, is also the data object, and is responsible for storing itself in the database, of course, for the persistence of this piece of code should have a corresponding implementation in the parent class.
That is, the ORM model defines a table mapping to a class, a record mapping to an object, and a field mapping to a property. With naming conventions and configuration conventions, we are able to achieve a large degree of operation of the model and are easy to understand. But the main idea of AR also encapsulates part of the business logic, and it itself is responsible for persisting itself, that is, usually AR is more suitable for single-table operation.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Sinsing analysis of several nouns around data manipulation: Model, DAL, DAO, ORM, and AR