我应该使用实体框架而不是原始 ADO.NET

Question

我是 CSLA 和实体框架的新手。我正在创建一个新的 CSLA / Silverlight 应用程序，它将取代 12 年的 Win32 C++ 系统。旧系统使用自定义 DCOM 业务对象库并使用 ODBC 访问 SQL Server。新系统不会立即取代旧系统——它们必须在未来几年内与同一个数据库共存。

起初我认为 EF 是最好的选择，因为它是最新最好的。在制作了一个小型 EF 模型和只有 2 个 CSLA 可编辑根对象（我最终将拥有数百个对象，因为我的数据库有 800 多个表）之后，我严重质疑 EF 的使用。

在当前系统中，由于 100% 控制生成的 SQL，我需要多次对查询进行精细的性能调优。但在 EF 中，幕后似乎发生了很多事情，以至于我失去了控制。像http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html 这样的文章不利于我对 EF 的印象。

由于 LINQ to EF，人们似乎喜欢 EF，但由于我的标准是在客户端和服务器之间作为标准对象传递的，因此我似乎可以在没有 LINQ 的情况下轻松构建查询。我在 WCF RIA 中了解有查询投影（或类似的东西），我可以在其中执行客户端 LINQ，它在转换为实际 SQL 之前确实移动到服务器，所以在这种情况下，我可以看到 EF 的好处，但在 CSLA 中看不到.

如果我使用原始 ADO.NET，5 年后我会后悔我的决定吗？

最近有没有其他人做出过这个选择，你选择了哪条路？

Answer 1

在你的情况下，我仍然会选择 EF 而不是手动完成。

为什么？ EF——尤其是在 .NET 4 中——已经相当成熟。与您必须手动编写数据访问代码相比，它可以让您更轻松地完成大部分数据库操作，并且使用更少的代码。

如果您确实需要绝对最高性能，您始终可以插入存储过程以进行插入、更新、删除，然后 EF4 将使用这些存储过程，而不是动态创建 SQL 语句的默认行为。

EF4 具有更好的存储过程集成，这确实开启了两全其美：

• 在性能不是最重要的 80% 情况下使用 EF 的高生产力
• 对剩余的 20% 进行微调和手工存储过程并将它们插入 EF4

查看一些资源：

• Using Stored Procedures for Insert, Update and Delete in an Entity Data Model
• Practical Entity Framework for C#: Stored Procedures (video)

Answer 2

您似乎有多种需求和多种解决方案。

我通常将每个要求都用必不可少的、很高兴拥有而不是必不可少的来评价。然后看看有什么效果。

我同意@marc_s 所说的，你可以两全其美。

我要说的另一件事是，如果这个解决方案要在未来 5 年内出现，你是否考虑过单元测试？

plentyofexamples 介绍了如何使用 EF 进行设置。 （我个人避免使用 ADO.Net 只是因为分离关注点对于单元测试来说非常复杂。）

没有简单的解决方案。我会在你的项目中选择一个需要你一天左右的时间来完成的功能。尝试不同的方法（原始 sql、EF、EF + 存储过程），看看有什么效果！

Answer 3

客观地查看 CSLA - 调用“DataPortal”并查看调用堆栈。

接下来，将这些类放在 CI 构建服务器上，该服务器存储运行时数据并提供一系列运行的散点图。

接下来，查看创建的代码。问问自己，如何根据依赖于具有受保护/私有构造函数的静态创建者的类来使用依赖注入之类的东西。

接下来，看看“CSLA”类承担了多少责任。

最后问问自己，为每个环境创建具有不同构造函数的对象是否有意义，并问问自己将如何对它们进行单元测试。