存储过程与 Entity Framework

人们已经写过许多以对象关系映射（ORM）工具及其种种问题为主题的文章。大多数反对意见可归为两类：关注点分离和面向对象设计。对于 Entity Framework（实体框架）而言，我们有些好消息。

关注点分离（Separation of Concerns）

存储过程（Stored Procedure）不仅仅是将多得简直荒唐的业务逻辑塞入数据库的一种方式；它还是避免将多得简直荒唐的存储逻辑塞入应用程序层（application layer）的一种方式。它使得应用程序可被视为理想的数据表现，同时又不会泄露数据库管理员（DBA）的神机妙算。各种各样的暂存表、非规范化的报告表、视图、以及表函数都被隐藏在简单的存储过程调用背后，从而形成了数据库的公共应用编程接口（API）。注意，从微小的性能调整到全面重构的一切都可以完成，且无须重新部署许许多多依赖于该数据库的应用程序。

对于接下来的两个版本，Entity Framework 打算让使用存储过程变得更容易。在即将发布的版本 5 中，我们发现急需表值（Table-valued）函数，以及往模型中批量导入存储过程的能力。

表值函数（Table-valued functions，缩写为TVF）与对象关系映射工具的配合可谓天衣无缝。与普通的存储过程或视图相比，表值函数则要灵活许多，不过离开了动态SQL 语句生成，那么就无法充分利用它们了。而且实际上，SQL 语句生成是将对象关系映射从被美化的数据映射器中分离出来的关键功能。

遗憾的是，只有开发者可以使用这些建模工具。如果你正在用Entity Framework 的Code First 技术，那么你必须一直等到 Entity Framework 6 才能获得某种形式的存储过程支持，而对表值函数的支持就更别提了。

面向对象设计（Object Oriented Design）

面向对象程序设计是个棘手的话题。从本质上讲，对象关系映射工具希望简化为数据传输对象（Data Transfer Object，DTO）风格的一些对象，即拥有默认构造函数和公共属性，从而对象关系映射工具就可以分层执行延迟加载、跟踪变更等等。但是那些偏爱面向对象设计的开发者往往喜欢拥有复杂构造函数、以及有限的公共接口的复杂对象（rich object）。譬如CreatedBy（创建者）或CreatedDate（创建日期）这样的列应该用只读字段和相应的属性来表示，因此就没有机会意外更改它们的值了。

遗憾的是，我们近期内将不会看到这种情况。你可以使用私有设置器（private setter）来完成某些事情，但总体而言，与真正的业务对象相比，实体仍然还是更像数据传输对象。长期来看，自定义Code First 约定（Custom Code First conventions）会有所帮助。这个有前途的功能本打算成为EF 4.1 的组成部分，但是由于该设计的复杂性而被砍掉，而且总体感觉它只是没有准备好。Sergey Barskiy 写了一篇文章来说明本打算做些什么。

查看英文原文： Stored Procedures and Entity Framework