Chapter1-data access reloaded:Entity Framework（下）

1.4 Delving deep into object/relational differences 深入挖掘对象关系的不同

理解面向对象和关系世界的不同是重要的，因为他会影响你设计一个对象模型或者领域模型以及数据库。
这个不匹配被拆分成了几个部分：数据类型的不匹配,关联的不匹配，颗粒尺度的不匹配，继承的不配，识别的不匹配，在下面的几个部分，我们会轮流的探究他们，为了更好的阐述这个不匹配，我们还会使用前面提到的例子。

1.4.1 The datatype mismatch 数据类型的不匹配

数据类型的不匹配是指对象和关系使用的数据表现和约束是不同的，当你往数据库中的表添加一列的时候，你必须要给他制定一个类型，现代数据库支持char,varchar,int,decimal,data等等，当类面对这个的时候，情况变得不同，数据库的Int和bigint类型非常适合.net的Int32,Int54类型，但是其他的数据库类型在.net里面没有一个转却的匹配，你 可以在列上设置一个约束来强制业务规则，当我们的数据库是为好几个应用程序服务，并不是只有你更新数据的时候的时候，这是非常值得期待的事情，在.net里面，varchar是不存在的，最相近的类型是String，但是它不支持声明长度限制（它可以保存2G的数据），如果你想检查String的值不超过期望值，你不得不在set属性中实现这个坚持，或者是在发往数据库之前调用一个检查方法。
另一个关于数据类型不匹配的例子是二进制数据，每个数据库都接受二进制数据，但是含有二进制数据的列不知道这个数据代表的是什么，它可能是text或者PDF文件，图片等等，在.net中，你可以用一个对象来表示这个列，但它将是无意义的，因为如果你知道这列存储的是哪种数据，如果是文件你可以使用流对象，如果是图片Image是最好的选择。
最后一个关于类型的不同是当你使用date的时候，根据数据库供应商和版本，你可以有很多的数据库类型供使用去存储一个日期，举例子，在SQLServer2005之前（包括），你可以使用DateTime和SmallDateTime，SQLServer2008又引入了两个数据类型：Date,Time,如你所想，Date只包含日期，Time只包含时间，在.net中，你只有一个DateTime类去表示Date和Time，处理这个不匹配并不十分困难，但是反过来，but it requires a bit of discipline when instantiating the object
from database data and vice versa.

正如你看到的，数据类型的不匹配是很平常的，并不会引起开发人员晚上失眠 ，但是它确实存在，而且你必须要 考虑的事情。第二个不同是关联的不同，在1.2会碰到，数据库使用外键去表现关联，然而面向对象的应用程序使用引用，在下个部分我们会深入这个话题。
1.4.2  关联不匹配
当我们讨论Association的时候，关系和对象世界的最大不匹配是关系如何维护的，数据库表使用一个不同于类的机制。让我们检查两个世界的基数关系（一对一，多对多）是如何处理的。
一对一关系订单表拥有关于订单的所有数据，但是假设应用需要改进，一个额外的列需要添加到Order订单表,这可能看起来是一个很小的改进，因为添加一列并不是特别的危险，但是严重的不是这个，可能有很多的应用程序依赖于这个表，如果你不想避免引入Bug的话，机制的做法是创建一个新表，新表拥有一个OrderID和一个新列，从数据库方面来说，这是一个可以接受的折中方案但是在对象世界中重复这一的设计是无意义的，最好的方式是在Order类中添加一个属性。

同数据库交互的方法会处理两个模式之间的不同，这个方法一点都不复杂，它在两个表做了一个Join，并更新数据去处理这个不匹配
Select a.*, b.* from Orders a join Order2 on (a.orderid = b.orderid)
This association difference leads to the granularity mismatch, which will be discussed
later in this section.