实体框架 - 我应该承担风险吗？

Question

我使用传统的WebForms和Stored过程来完成一些非常复杂的项目。然而，最近我使用MVC和实体框架做了一个项目，我喜欢它们与Entity框架一起工作的方式。它们可以让你以面向对象的方式处理实体......真棒。该项目并不复杂。大约12-15个表。

我们都知道WebForms和存储过程更成熟，因而是可靠的技术。据我所知，EF仍在不断发展。它甚至没有非常基本的“唯一约束”。虽然有办法解决问题，但在使用EF开始项目之前，我会三思而后行。

我想问的是，如果我想开始另一个庞大而复杂的项目，我可以选择使用MVC＆amp; EF？是否存在遭遇死胡同的风险？

Answer 1

我个人在每个新项目中使用EF和MVC。我还没有遇到一个缺点。相反，我发现MVC要好得多。关于存储过程，它们仍然并且总是比运行TSQL ad-hoc更有效..只需用EF替换普通的ADO.NET代码并继续使用存储过程。至于唯一约束，你仍然在数据库本身做那些。更多信息：

Unique constraint in Entity Framework

在这里：

Does Entity Framework 5 support unique constraints?

此外，请检查此链接以使用存储过程和特殊TSQL查询与EF：http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/advanced-entity-framework-scenarios-for-an-mvc-web-application

Answer 2

将EF和MVC用于复杂项目的风险很小。如果使用EF，您仍然可以调用存储过程或执行动态SQL查询（不应该这样）。 EF为您提供选择。可能存在更多不使用它的风险。不要忘记SO是用MVC构建的。