我应该使用实体框架、数据集还是自定义类？

Question

我在这里真的很难过。我需要设计一个使用 WCF 作为通信渠道的“桌面应用程序”。它是一个多层应用程序（DB和应用程序服务器相同，客户端通过互联网云）。

应用程序比通常的 LOB 应用程序有点复杂（就 SQL 和代码逻辑而言），但概念是相同的：从 DB 读取、更新到 DB、处理并发等。我的问题是现在使用 Entity公开的框架，我无法决定采用哪种方式进行：我应该使用实体框架、数据集还是自定义类。

据我了解，Entity Framework 还将创建我的数据库表的对象映射以及 CRUD 脚本。这对于简单的 CRUD 来说一切都很好，但大多数时候“选择”很复杂，它需要自定义 SQL。我知道我可以在 EF 中使用存储过程（顺便说一句，我不喜欢 SP，我不知道为什么，我喜欢在 DAL 中手动编写我的 SQL，这样我感觉更安全和舒适）。

使用 DataSet，我将使用我的自定义 SQL 并填充数据集。使用自定义类（数据库表的对象），我将在这些自定义类（集合和列表等）上填充我的自定义 SQL。我想使用 EF，但我对部署未编写 SQL 且无法在代码中看到的应用程序没有信心。我在这里错过了什么吗？

在这方面的任何帮助将不胜感激。

习书

Answer 1

虽然 EF 与 WCF 一起使用并且听起来很有希望，但您应该考虑努力加快速度。特别是在做一些不重要的事情时，VS2008中的设计器无法再打开模型，您必须在xml中编码您的模型。

还请记住，EF 在非常高的抽象级别上工作。因为law of leaky abstractions 它并不像它应该的那样闪亮:) 反过来说，当涉及到故障排除/性能问题时，您必须处理发送到数据库的非常疯狂且难以阅读的 sql 语句。

Answer 2

我同意 Marc G. 100% - 数据集很糟糕，尤其是在 WCF 场景中（它们为处理内存中的数据操作增加了很多开销） - 不要使用那些。它们可能适合初学者和小规模的两层桌面应用程序 - 但我不会在严肃的专业应用程序中使用它们。

基本上，您的问题归结为如何将数据库中的行转换为您可以跨 WCF 远程访问的内容。这意味着某种形式的映射——要么你自己做，使用 DataReaders，然后将所有数据推送到 WCF [DataContract] 类中——你当然可以这样做，给你最终的控制权，但它也很乏味、麻烦和错误——易发。

或者您让一些现成的 ORM 为您处理这项繁重的工作 - 在 Linq-to-SQL（出色、易于使用、灵活，但仅限 SQL Server）和 EF v4（3 月推出）中任您选择2010 - 看起来很有前途，非常灵活）或任何其他 ORM，真的 - 最适合您的需求。

ORM 领域的其他重要竞争对手可能包括 Subsonic 3.0 和 NHibernate（以及许多其他产品）。

总结一下：

• 忘记数据集
• 要么你有 100% 的控制权，要么你自己控制 SQL 和你的对象之间的映射
• 你让一些有能力的 ORM 来处理（Linq-to-SQL、EF v4、Subsonic、NHibernate 等）——这真的无关紧要，也就是说，这也是个人喜好和编码风格的问题

Answer 3

我无法提倡数据集，尤其是在像WCF这样的SOA环境中 - 它将工作，但主要是错误的原因。他们根本不是便携，并且imo并没有真正“工作”在服务边界上。当然，imo他们也不在大多数其他场景中工作;-p

所以那时它归结为你想做多少管道。大多数ORMS将为您创建WCF-Serializable类型;我个人 em>我目前使用linq-to-sql;它既比EF又比EF更简单，更完整，尽管EF 4.0意味着3.5SP1中的EF会好得多。您可以使用自定义TSQL（通过ExecuteQuery，@仍然映射回对象），但我倾向于使用SPROC（用于复杂查询）或LINQ生成的查询（用于简单请求）。

写入类型也很好，并将与nhibernate等合作。