我们应该使用实体框架吗？

Question

我们目前有以下堆栈：

• VS 2005
• Web表单
• Server 2005
• IIS 6

我们正计划向此过渡：

• VS 2010
• MVC和Web表单
• Server 2008
• IIS 7

我的问题是，当我们使用VS 2010迁移到MVC时，我们应该使用实体框架(或另一个ORM)、微ORM (比如海量)，还是仅仅使用普通的SQL？

我所读到的关于VS 2010的所有教程都是针对使用实体框架进行数据事务的，但是在可预见的未来(5+年)会不会出现这种情况呢？

如果有关系，我们客户端的应用程序可以有10,000个活动用户。

Answer 1

最近，我从使用内联SQL查询转向使用EF，下面是我的发现：

优点

• 构建DAL要快得多(我不喜欢编写SQL查询！)
• 维护起来容易得多
• 在构建内联sql语句之前，不再需要记住解析我的输入，这意味着SQL注入攻击的可能性更小(当然，取决于查询，这仍然是可能的，但可能性要小得多)。

缺点

• 不能跨越多个数据库..。至少不容易
• 所有实体(表、视图等)都需要一个主键。
• 如果您想要更新100+必需列表中的单个列(不是我的表设计)，则必须下拉所有100列才能进行更新。或者使用存储过程。
• 在添加新记录之后，在SQL服务器上定义的一些默认值没有被拖到实体模型中，我遇到了一些问题。通常这是与计算值，或在插入触发器中添加的值一起使用的。
• 有时，SQL查询编写得很糟糕，执行速度也很慢。如果您有一个运行缓慢的查询，请运行一个SQL跟踪以查看EF正在做什么。您可以将该查询重新处理为SP或View。但这种情况并不经常发生。
• 在试图在没有在Server中定义外键的表之间创建关联时，我遇到了一些问题。通常是因为我试图创建一个1:0-1关系，EF想要使用1:0-*

我不是EF专家，所以我可能错过了一些事情。这些只是我以前在从内联SQL切换到实体框架时输入的内容。我很高兴我做出了转变，但也有一些时候，我真的恨EF，因为它的怪癖。

Answer 2

实体框架是一种生产力工具。除非您有很好的理由不这样做(例如，您正在使用SQL 2000或没有时间增加技术)，否则请使用您可以使用的最佳工具。

尽管如此，我发现实体的概念可以很好地转化为MVC模式的模型。虽然与模型和表保持1:1的关系是一种糟糕的做法，但就实体而言，思考往往会产生简洁的设计，易于阅读代码(尤其是使用LINQ)。

实体框架受到Microsoft的积极支持。没有人有神奇的水晶球说“支持将持续X年”。我看不出有什么理由相信实体会在未来5年内死去。

Answer 3

另一个潜在的解决方案是使用另一个实体框架库，这个库不是提供给V.S的。

实体/3层框架的概念已经存在了一段时间，在微软发布自己的“官方”框架之前，它已经和许多其他开发人员一样，与几个自定义库一起工作。

Pros

享有实体的利益(D.A.L.)框架，不受Microsoft常量库/框架更改的困扰。

向库中添加一些现有官方库可能无法使用的特性，比如使用几个dtabase品牌。

Cons

必须支持库或工具。通常有一个实体生成器代码工具来生成enitites。