由于之前已经尝试使用过 EF CodeFirst CTP4，所以这次在EF4.1发布的第三天，在 OEA 框架中已经支持使用它来实现数据访问层。而且，我们准备逐渐把原有的较量级ORM框架给替换掉，并且使用EF中的元数据系统来完全充当 OEA 中的 ORM 元数据，以便使用这些映射信息来实现一些更多的操作。由于还没有时间把整个 EF 的 MSDN 拿下，所以暂时只是在网上看了一些相关的文章。而最近又正好在重构 OEA 框架的元数据子系统，所以，这篇文章里，我主要对 EF 的元数据进行一个简单的分析。
注意，以下的分析只代表我的个人观点。
不了解 EF 元数据的朋友，我这里给出一篇我觉得写得蛮不错的查询文章：《.NET - ADO.NET Entity Framework : Querying metadata》，大家有兴趣可以看看。这次，先给出我认为 EF 的质量分析，方便以后查看，接下来的文章会进行一个更详细的分析：
可扩展性：★★★★★
性能：★★
API易用性：★★★
模型基本概念
在整个EF的映射信息中，分为 Object Model、Conceptual Model、Storage Model、Object-To-Conceptual Model、Conceptual-To-Storage Model 五大类。前三类是表明静态结构信息，后两类表示静态结构间的映射信息。这五类元数据，全部都由一个灵活度极强的元数据系统来描述。
Object Model 表示对象模型，该元数据说明了运行时对象的特征，如：CLR运行时类名、属性名等。
Conceptual Model 表示逻辑模型，该模型与数据库元关、与程序无关，用于描述逻辑上的“领域模型”或者“业务模型”。
Storage Model 则表示数据库中的静态信息，如：表名、列名。
而这三类模型间有许多的共通之处，例如，都可以用一个统一的概念来描述不同模型中的不同概念：用“实体类型”来描述对象中的类、数据库中的表、概念模型中的领域实体；用属性来统一描述类的属性、表的字段、实体的属性。所以 EF 使用一个简单的 EntityType 来描述实体类型、用 EdmProperty 来描述实体属性。
但是，它们之间必然存在差异。这就意味着，同样的一个 EntityType 类型，需要支持不同的属性。
属性扩展
针对以上问题，EF 给出了一个可扩展属性的设计：
MetadataItem 作为所有元数据类型的基类，使用集合的方式来提供了类似于 DynamicObject 一样的属性扩展系统。每个子元数据类型都通过 MetadataProperties 集合来定义/添加自己支持的属性 MetadataProperty，该类声明以下：
例如，StructuralType 类型中强类型属性 Members 是成员的集合，
运行时视图如下：
而继续调试到基类，会发现 MetadataItem 中的 MetadataProperties 属性集合中有一项正好就是名字为 Members，而值是恰好是刚才 5 个成员的集合：
所以，不用看源码，我们也可以大胆地猜测，在 StructualType 中，Members 这个属性的内部实现其实就是在基类的集合中注册一个新的 Metadataproperty 项。
可以看出，这是一个动态属性注册的机制，动态语言运行时中的 DynamicObject、WPF及WWF 中的 DependencyProperty，都有类似的设计思想在其中。
这样的机制可以让我们不断扩展属性；不需要转换为子类就能以“非反射”的方式来对各个属性进行控制；换来的却是属性系统的性能相对低下。
类型扩展
第二个较大的扩展点在于：元数据类型是可扩展的。
在之前给出链接的文章中，可以看出，系统已经给出默认了许多元数据类型，它们都位于 System.Data.Metadata.Edm 命名空间中，如下图中给出了一些重要的类型：
当然，这并不是全部的元数据类型。细看前面截图中，MetadataItem 有一个 BuiltInTypeKind 属性，它的类型是一个枚举，例举了EF中目前所有支持的元数据类型，不同的子元数据类型重写这个属性来返回不同的值。这个设计非常类似于 Linq 系统中 Expression 的设计，它们都在最顶层的基类中枚举了所有的子类，以方便通过枚举的判断来识别运行时的类型。但是它们又不尽相同：Expression 是表示编程语言中的表达式，而这些表达式是固定的，我们不会也无法去对它进行扩展；但是 EF 中元数据却是可以任意扩展的，这点可以从 BuiltInTypeKind 属性的名字中看出，它表示的是“系统内置的类型”，当然，也可以从 MetadataProperty 中的属性 PropertyKind 枚举看出，它有两个值：
Extended 就表示这个属性是“非内置”的。
有了这样的设计，理论上，我们可以在任意 dll 中扩展 EF 的元数据类型。而把实例全部都加入 MetadataItem 的集合中就可以了。
但是，这也带来了不利的方面，例如，在进行查询的时候，不能象一般的 API 一样进行强类型的导航。换句话说，我拿到一个 MetadataItem 的集合，如果我不把它们转换为子类型的话，无法进行强类型属性的使用，而只能使用字符串的匹配。所以，要对 EF 的元数据进行强类型查询，首先要了解整个元数据的结构，然后借助 Linq 中的 OfType<T> 方法来进行查询。例如，我在上面截图中，使用 OfType<EdmProperty> 的方式来查询给定类型中所有成员中的属性列表。这也导致了性能比较差。
为什么是这样的设计？
作为一个框架，不可避免地要进行框架的可扩展性进行设计，而且，这往往是非常重要的。而且我认为，在 EF 的设计中，可扩展性是是元数据模块的首要设计目标。
这样的灵活度要求，实出无赖：EF 作为一个通用的 ORM 框架，不但要同时描述对象模型、概念模型、存储模型，同时还要考虑到各种数据库的兼容，还需要保证未来可能出来的各种数据库、各种方法、各种存储结构都能被元数据系统支持并加以描述。
这样的结构，可以把任意的信息都设计出对应的类型，然后放入元数据系统中。这里，为什么能说任意呢，因为设计本身可以说是和 XML 格式等价，而目前 XML 作为一种通用的数据格式，基本上可以描述所有的数据。（具体为什么和 XML 格式等价，这里不再展开。）
结尾
扩展性对于框架来说非常重要，这样的一个元数据系统设计，对于我来说，是十分有诱惑力的。我曾几次考虑是否把 OEA 元数据系统设计成类似的结构。但是，最终还是没有这样做。原因在于，在进行系统/框架/架构设计时，各种质量属性都需要进行权衡，不可一味地追求某一个属性，而是应该找到适度的设计。这是一句老话，但是往往做起来很难。
程序设计是一门艺术，而权衡则是一辈子都要玩的艺术。