导言：在探寻根源篇章【编程·落地与升华·框架篇】实战·手写ORM框架（一）探寻根源 中，我们深刻剖析了O/RM的思想基础，并提出了部分技术方案。在这一篇中将进行技术选型并尽量找出问题的关键。
一、技术选型：
在探寻根源篇章中，提出了3*3=9种组合方案（实际方案千变万化，不止于本文），最终我选定了【泛型类+特性（C#的一种特殊语法）】作为描述【类与映射】的解决方案。
原因阐述：1.因为我做过，同时也是主流的方案，用起来最爽（不包含运行时效率），做起来最复杂，同时又很精致，技巧十足。其中涉及的知识点非常多，把最难的学会了，其他的呢？特性（Attribute）是用于在运行时传递程序中各种元素（比如类、方法、结构、枚举、组件等）的行为信息的声明性标签。您可以通过使用特性向程序添加声明性信息。一个声明性标签是通过放置在它所应用的元素前面的方括号（[ ]）来描述的。这个解释来自互联网。通俗点的解释呢，就是给程序中的一些元素做点小标记，如果在你身上贴一个工牌，表示你是个员工。同样，在C#中，对一些元素做标签，就相当于增加了一些信息
一、关键分析：
“如果你能在测试之前发现bug，那是一件很牛的事。如果你能在开发之前发现问题，那将是一件伟大的事。” ----蜡笔小黑 哈哈
技术选型之后的工作并不是开工，急于产出的一定不是代码，而是屎山。依然需要对问题进行进一步的分析，尽量跳过一些坑。根据上图分析，我们会发现O/RM的核心在于Mapping(映射)上，其中要处理的映射关系包含【类名/关系名】,【类属性/关系列名】，【数据类型/域】与【逻辑约束/关系约束】，当然还包括语言本身与建模所带来的的问题，比如C#是编译型（其实半解释）， 而SQL属于解释型，比如数据库建模应当使用逻辑主键而不用物理主键。
【类名/关系名】：通常企业内部都有着自己独特的命名规范，类名和关系名通常会有所不同，其中映射可以直接关联的，也可以是基于约定的，比如STC_Student表与Model_Student类的尾缀相同。
【类属性/关系列名】：同类名关系名一样，可以用约定也可以用直接关联的映射方式。
【数据类型/域】：坑来了，无论是关系型数据库系统还是面向对象编程语言，都有着自己独特的强类型体系，其中必然面临转换问题，特别注意空值处理，在面向对象端的空值表示是NULL型，而从数据库传递过来的确是DBNULL类型。
【逻辑约束/关系约束】：大坑来了，既然选用了ORM，在数据库设计时，就得尽量少用约束，约束越多，映射越笨重，例如在进行Insert操作时，对于自增列的处理，就应该屏蔽掉，不然不被数据库规则允许。
【编译型语言/解释型语言】：巨坑来了，编译型语言会被编译器严格检查，而嵌入式SQL语言在后端通常采用String类型表示，我们实现前后端通用访问通常采用拼装SQL语句的形式，而这种String类型在BdildingTime不被检查，未知的错误发生在运行时，这一点是致命的，比如SQL拼装错误带来的RuningTime异常，SQL注入引发的安全问题。
至此，关于映射的基本问题有了概要性的描述，接下来，我们要在代码中进行实现，请看下篇。