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

我们目前有以下堆栈：

• VS 2005
• 网络表格
• SQL Server 2005
• IIS 6

我们正计划过渡到此：

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

我的问题是，当我们在VS 2010中使用MVC时，应该使用Entity Framework（或另一个ORM），微型ORM（例如Massive）还是仅使用普通SQL？

我已经阅读了有关VS 2010的所有教程，都是针对使用Entity Framework进行数据事务而设计的，但是在可预见的未来（超过5年）中会存在吗？

如果有关系，我们客户的应用程序可以拥有10-1,000个活跃用户。

我最近从使用内联SQL查询切换为使用EF，这是我发现的内容：

优点

• 构建DAL的速度快得多（喜欢不编写SQL查询！）
• 容易维护
• 不再需要记住在构建内联sql语句之前分析我的输入，这意味着发生SQL注入攻击的可能性较小（当然，仍然可以根据您的查询，但是可能性要小得多）

缺点

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

我不是EF专家，所以我可能错过了一些东西。这些只是我过去从嵌入式SQL切换到Entity Framework时遇到的问题。我很高兴自己做出了切换，但是由于它的怪癖，有时候我真的很讨厌EF。

实体框架是一种生产力工具。除非您有充分的理由不这样做（例如，您使用的是SQL 2000，或者没有时间升级该技术），否则请使用最好的工具。

话虽如此，我发现实体的概念可以很好地转换为MVC模式的模型。尽管与模型和表建立1：1关系是一个坏习惯，但以实体的方式进行思考往往会产生简洁的设计，易于阅读代码（尤其是LINQ）。

Microsoft积极支持实体框架。没有人会说一个神奇的水晶球说“支持将持续X年”。我认为没有理由相信Entity将在未来5年内死亡。

另一种可能的解决方案是使用VS所不提供的替代实体框架库。网络上有一些可用的实体框架库。

Entity / 3层框架概念已经存在了一段时间，并且在Microsoft发布其自己的“官方”框架之前，已与其他许多开发人员一样使用了多个自定义库。

优点

拥有实体（DAL）框架的优点，而不会因Microsoft常量库/框架更改而陷入困境。

向库中添加现有官方库可能不可用的功能，例如使用多个dtabase品牌。

缺点

必须支持该库或工具。具有实体生成器代码工具来生成实体的情况非常常见。

您必须根据问题和现有解决方案做出体系结构决策。与任何技术一样，都有优点和缺点。

我个人通常会使用实体框架进行新开发，而不重写现有的工作代码。然后，您可以加快将来的开发速度，而不必花费大量时间转换代码。这种方法的缺点是降低一致性。

在您的情况下，我肯定会使用Entity Framework，我发现它可以与MVC很好地配合使用。
这里是一些真正的原因和指针。

• Linq使用起来很愉快，延迟执行也非常有用。
• 您可以生成模型（但是，当与mvc一起使用时，建议您将视图模型与数据模型结合使用，这会使验证和模型绑定更加容易，如果您采用这种方法，请使用automapper将更改映射回您的模型数据模型）。

但是，您需要了解许多有关使用ORM的知识。

• 上下文对您有什么作用（实体跟踪）
• 应将上下文用作工作单元
• 记住关于并发的事情，EF可以告诉您对象何时过期，但是如果您想跨请求正确处理并发（因为您需要保留时间戳等），这可能会很棘手。

要考虑的事情

• 触发器和ORM不能一起使用，请改用ORM事件。
• 确保您所有的表都具有前键。

即使您已有数据库，我也强烈建议您采用代码优先的方法。

• 这些约定意味着您在更改数据库时不需要重新生成映射或类。
• 在模型中放置验证和其他逻辑比较容易。
• 如果您拥有庞大的现有数据库，则可以使用代码生成器来帮助使它们。