10

我是 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 年后后悔我的决定吗？

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

4

3 回答 3

7

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

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

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

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

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

查看一些资源：

于 2010-05-23T21:26:02.240 回答
2

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

我通常用必要的、很好有的、非必要的来评价每一个要求。然后看看什么有效。

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

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

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

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

于 2010-05-23T23:41:30.513 回答
0

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

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

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

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

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

于 2010-06-25T00:03:37.753 回答