First, what is the O / RM (Object Relation Mapping Object-relational mapping)?
Relation Relationship: from a mathematical in nature, is more than a set of subsets (depending on a relationship) after the Cartesian product.
Object Object: object development from idea-oriented, object-oriented development is the fundamental particles.
When using an object-oriented approach to program design and implementation, if the data persistence solution when using a relational database implementation, communication and database back-end process of thinking will inevitably lead to conflict in nature (object-oriented and relational models), technical conflict. To address this problem, the original approach by the host program (such as C #, Java and other object-oriented languages) in the database access tools (such as ADO.NET) to write embedded SQL, and establish appropriate relationships with the database schema entity type, by hand writing specific communication process to transfer data.
Obviously, the lack of such an abstract way the upper and did not fundamentally solve up, is a temporary approach, in which both ends of the communication by the body and ever-changing business impact, which maps change with the huge changes will inevitably lead to the difficulty of software development increases, increased maintenance costs, then there is no way to be able to solve this problem?
A: O / RM, i.e., object-relational mapping, an object-oriented programming mode to build the frame of High correspond reusable. Consistent programming ideas (object-oriented) to communicate with back-end code expression database. Even the developers did not understand the language database can be carried out safely and effectively for program development.
So look, good magic ORM, but he also has drawbacks, like the Chinese proverb translated into English, no matter how you translate, he can not be authentic with minimalist expression of profound description of the contents, which are two cultural differences, ideological, like O / R, as has always been part impossible. So for software development engineers, database technology remains a priority. In addition, to achieve high reusable higher level of abstraction usually with a loss of performance will run, on this point, ORM is not as good as the traditional way.
O / RM is not new technology, there are many proven solutions, such as Mybatis Java environment, Hibernate, etc., EF Net framework the environment. So why should we try to do handwriting? In fact, this problem is very simple, the individual, is a good way to exercise technology, to enterprises, not every technical framework for an ORM can fit under the bureau, some too simple, but some cumbersome. Moreover, even if the ORM has matured, there are still some things can not be done, why do not we try it?
Second, a deep understanding of O / RM process, search the root of technical landing
Case conventional manner: Firstly Student entity class, the class is instantiated Liubei (Bei) for receiving the object data, and then retrieved through PKey embedded SQL statements to retrieve the transmitted data is written to the attribute object Liubei background after parsing.
Sample code:
This is a logical expression of the basic code but not reliable, reliability aside, the basic logical terms, the method is implemented from the Student table and read from a tuple of data values in accordance with the retrieved Pkey Student class object process, whether it is Joe Smith or John Doe, we can call this method through a dynamic relationship to achieve the transformation from an object.
However, this code only achieve code reuse in the Student category, again if a "class teacher / teacher table '", "curriculum classes / curriculum" mapping How do we achieve it? Analysis, logic and the above method is basically the same, do not want to copy and paste the above code change the method name and return value type? Answer later.
"When we want to keep things status quo, it's time to change that must take place with" - Giuseppe Tuoxi Ma · flute · Lampedusa, "Leopard"
Software complexity from the "Change", to which we can analyze object-oriented features three basic "package idea."
For example, the life of the courier service, whether you send or receive a keyboard and mouse or, cosmetics or, couriers will always tell you on the phone: "Mr. (Miss or), your express (or package) Arrived"! There can be seen here, for the courier, he does not care about you is exactly what was inside the business point of view he should not care, he should be concerned with information about the package, such as the sender, mailing locations, accepted people receiving location, recipient contact information. In this way, the courier will ignore those changes unrelated to (what exactly is installed), and more focused on their business.
那么什么是封装？如果你觉得仅仅是用一个包裹把东西包起来，那就说明要走的路还很远。就快递案例分析，包裹概念的提出不是没有根源的，基于生活经验，我们可以将“邮寄的键盘”、“邮寄的鼠标”、“邮寄的香水”归纳为“邮寄的东西”,我们称之为包裹，这是一种抽象层次的自然上升，就像“身高”概念的提出，归纳了170.180.190cm等无穷无尽的可能，这样我们人脑能够接受并处理的信息才不会爆炸，人类语言的构建过程就是这样，不断地归纳信息，通过一种不变去屏蔽变化。我们在进行软件设计时同样会面临这样的问题，不同于生活经验，计算机逻辑或业务逻辑的陌生感让我们不太容易找到那个“不变的东西”，也许正是如此，才更有价值。
回归主题，面对O/R通讯问题，传统方式会将变化封装在特定的类内，通过代码我们发现，其实可重用的地方还很多，那么我们如何去解决这个问题呢？
看似是一个代码重用问题，实则是关于设计的问题。通过代码看问题，解决过程会非常精致，但却略显狭隘。缺乏较高层次的归纳。
我们不妨试着画一张图：
画这张图需要一点基本功，是关于面向对象与数据库系统的基本知识。万丈高楼平地起，基础概念体系的建立程度往往决定了技术发展的未来。
·关系型数据库系统基本概念“：
1.关系：数据库里的一张表，有具体的结构，有数据。比如学生表，其中存有张三李四等人的信息。
2.关系模式：关系的抽象描述，有具体的结构，没有数据。比如一张学生表或一张教师表。
3.关系模型：关系模式的抽象，用于描述什么是关系模式，说明了关系模式“要有”表名，列名，域，约束等。
·面向对象的基本概念“：
1.对象：面向对象程序中的基本操作单位，包含具体的结构与值。例如一个具体的一个学生张三。
2.类：对象的抽象，有具体的结构，但没有数据，例如学生类、教师类等。
3.类的元描述：类的抽象，描述了什么是类，例如类要有名称，要有属性，要有数据类型，要有方法等。
基于上述概念分析，真正进行数据传递的是对象与关系，如张三与关系中的元组（数据库的一条记录）张三，或一个集合对象对应一个关系。为寻求一致的方案，解决这个实际的通讯问题，我们可以进行两步抽象：
第一步，将【张三对象/张三元组】的【数据传递】归纳为【学生类/学生表】的【具体映射】，其实这就是我们的传统做法，实现了无论是张三还是李四，只要他是学生，就可以通讯。
第二步，为达到更高层次的复用需求，我们再次向上归纳，我们发现，无论是学生表还是老师表，最终都是表，无论是学生类还是教师类，都是类，由此，我们找到了问题合适的终点（不要过度设计）。其实我们所做的映射，本质上就是在做（【类名/关系名】,【类属性/关系列名】，【数据类型/域】，【逻辑约束/关系约束】）的映射。
回到出发点，我们本质上是想在“后端”程序中实现这个转化过程，而不是在数据库端完成，所以我们应去寻找关于“类”向上抽象的解决方案，实际上就是在表达类的描述。
借助面向对象工具（本文采用.NET平台，C#编程语言），比如可以使用抽象基类（将所有要进行通讯的实体类都继承这个类）、泛型类（通过制定运行时泛型指定来描述实体类）,甚至我们可以使用一个属性的集合来表示（对象与数据库的通讯，实际本质上就是类的属性在进行通讯，这种只含有Get Set方法的模型被称为贫血模型，所以一定程度上，我们可以用一个属性集合来表征与数据库通讯过程中特定的类的描述）。
具备通讯实体的定义能力之后，我们需要去表达映射，就单表单对象通讯来说，对象属性和表的列名不一定一致，传递过程要建立一种特定的映射，而这种特定的映射也是可以进行抽象表达的，比如使用XML配置文件存储、静态或非静态类存储、或者利用特定语言的语法，比如C#中的特性来进行描述。
| 映射描述 \ 类元描述 | 抽象基类 | 泛型类 | 属性组合 |
| 配置文件 | 1 | 2 | 3 |
| 类文件 | 4 | 5 | 6 |
| 特殊语法 | 7 | 8 | 9 |
至此，根据类元描述方式与映射描述方式的不同，提出了9种解决方案，那么究竟孰高孰低？异或都有什么各自最适合的应用场景呢？深夜已至，我已无力再战，以后有时间逐一分析，但是各位看客，希望能独立思考，在我接下来的实现篇中逐步体会。