不使用数据集的 N 层架构（数据集听起来对性能很不利）

Question

我阅读了有关 n 层架构的书籍、文章、教程以及所有此类内容，并且我正在尝试应用著名的 3 层（DAL、BLL、PL）。我刚刚进入游戏，实际上，我已经阅读了很多有关将整个数据库加载到内存中（数据集所做的）有多么糟糕的文章，尤其是当我需要查看某个项目的详细信息时，这将不得不从 5 个表或其他东西中检索，所以会很多，而且我只想要一条记录！这是我需要很多记录的唯一情况，一次不会太多，它将检索非常简单的信息（id、姓名、地址），如下所示！

您认为找到另一种方法来创建没有数据集的 DAL 和 BLL 更好吗？还是数据集更好？如果数据集对性能等不利，您有任何材料可以教我如何做到这一点吗？

Answer 1

大多数所说的都是中肯的建议。我同意，如果您打算投入时间来构建 N 层应用程序，那么您应该考虑考虑 ORM 解决方案。如果您正在基于 .NET 技术进行构建，那么 EF4 是构建 DAL 的一种非常好的方法。

您对 DAL/BLL 应该返回的内容的理解肯定存在混乱。数据集现在在 .NET 3 和 4 中有点过时，尽管并不罕见。在构建 DAL 时，您应该阅读存储库设计模式。根据实现的不同，您的存储库通常会返回一个通用的 List。或 IQueryable。 IQueryable 是我的偏好，但是，有人认为它模糊了 BLL 和 DAL 之间的界限。

一些实现还要求每个聚合都有自己的存储库。 （即 CustomerRepository、EmployeeRepository）我发现创建一个类型有约束的通用存储库是最简单也是最好的方法。

例如：

Repository: IRepository;其中 TEntity : ITrackable

要了解设计 DAL 的好方法，请查看 nCommon。
Tony Sneed 有一个关于将实体框架与 POCO 结合使用的精彩博客系列：
http ://blog.tonysneed.com/2010/02/19/trackable-dtos-take-n-tier-a-step-further-with-ef4/

设计 DAL 和域层所花费的时间至关重要。

我的建议是主观的，不应被视为正确或错误。不知道你的申请要求。如果您可以使用简单的数据集和 sqldatareaders 更快地编写一些代码，那么您的投资回报可能会更大。如果您希望构建可维护的设计，请像其他人建议的那样，花额外的时间阅读 EF4 和 N 层架构模式。

---

[编辑]

为了回应您下面的评论，我想我可以分享一些我在学习建筑时发现的宝贵资源。

首先，准备好投入无数个小时的阅读和重读。利用您当前的知识并不断练习，应用您所学到的知识。最重要的是要认识到：你的设计永远不会是完美的，因为不存在这样的事情，并且仅仅因为你应用了一种模式并不一定会使其成为最好的。

拥有自己的个人项目对于在 OOP 领域取得进步是非常宝贵的。在马尔科姆·格拉德威尔 (Malcolm Gladwell) 的《异常值》一书中，他提出理论，平均需要 10,000 小时的练习才能掌握某件事。因此，继续编码和学习。 :)

您可以选择的最好的书籍之一是 Head First - 设计模式。它被高度评价为一本出色的 OOD 入门书籍，并且改变了您对代码的思考方式。我记得读完几章后立即意识到，“哇！我一直在编写这样的代码，但从来不知道它有名字！”它帮助我意识到设计问题是多么熟悉；他们有通用的解决方案，以及能够与其他开发人员沟通这些解决方案是多么重要。那本书会严重地打击你的屁股（以一种好的方式）。

但请注意，架构和设计书籍将为您提供设计应用的场景以及模式的实现。我花了一段时间才意识到可以有很多方法来实现该模式……尤其是在 .NET 中。当您开始阅读 Martin Fowler、Robert C. Martin、Eric Evans、Dino Esposito 的书籍时，您就会发现这一点。

有许多优秀的免费在线资源，例如 Microsoft 的应用程序架构指南。学习技术的一些最佳方法就是阅读博客。

对于实体框架，很难击败 Julia Lerman 的编程 EF4。至于阐明 ORM 的作用 - 它促进与数据库的通信，并允许您像面向对象一样“查询”它。例如一些伪代码：

查询

使用 SqlDataReader，您通常会运行类似"SELECT * FROM Users WHERE Users.UserId = 1" 的

使用 ORM，您实际上并没有编写 SQL。 ORM 将数据库表映射到实际的类对象，从而允许您查询强类型对象。因此，您可以编写如下内容：

User user = EFContext.Users.Where(u => u.UserId == 1).SingleOrDefault();

ORM 负责将其转换为 SQL 并执行查询。这种抽象还允许 ORM 通过提供程序可扩展性与多个数据库（MSSQL、Oracle、MySql）配合使用。

当您开始涉及分层架构时，您的 存储库 负责与 ORM 或数据库进行通信并返回您的结果发送至您的 BLL。例如，一个基本示例如下所示：

using (varrepository = new Repository())
{
用户 user = repository.Where(u => u.UserId == 1).SingleOrDefault();
这

是 ORM 及其使用方式的非常基本的定义。一旦你开始学习模式：如何识别它们，何时使用它们（并非总是如此，因为它们可能会使简单的事情变得过于复杂）并重构你自己的代码，然后开始阅读领域驱动设计。

希望这有帮助。

---

[编辑2]

当然，让我澄清一下每层实际返回的内容。根据您的存储库实现和设计决策：

从 ORM 所在的基础设施层，您通常会返回通用 List 或 >IQueryable 其中 T 代表您的对象。实体对象还是 POCO 由您决定。 POCO 只是一个代表数据的类，但它不仅仅是一组 getter 和 setter。它至少应该包含验证。阅读贫血领域模型以及如何避免它们。

从包含业务逻辑的域层，根据您尝试实现的松散耦合程度，您可以返回 List、BindingList，或者您将使用映射技术将 DTO 集合返回到表示层和服务层。

DTO 增加了另一系列的复杂性，但对于某些场景来说是必不可少的。 DTO 是不可变的对象。它们应该这样构建：

[DataContract]
public sealed class UserSummary : IDto
{
[DataMember]
public String FirstName { get; private set; }

[DataMember]
public String LastName { get; private set; }

[DataMember]
public UserProfile Profile { get; private set; }

public UserSummary(String firstName, String lastName, UserProfile profile)
{
    FirstName = firstName;
    LastName = lastName;
    Profile = profile;
}

}

它们只是的 getter 和 setter 包。您的 POCO 应该能够轻松映射到它们，并且有一个出色的软件可以使此过程变得简单：AutoMapper。它们不必代表数据库或 POCO 对象中的精确表，但可以包含其中的多个部分，如上所示。

有一个问题。有时，DTO 的信息不足以返回到您的服务或 Web UI。您通常还需要返回验证结果、错误处理信息，可能还需要返回一个布尔值来表示事务的结果。

该对象没有确切的名称，但我将其称为响应传输对象，它由 List、来自 Microsoft 企业库的 ValidationResults 以及我需要的任何其他内容组成知道。

这需要消耗大量信息。在学习 NLayer 开发时，像分解每一层一样将其分解。一次学习一件事，写下你脑海中出现的每个问题。请务必寻找这些答案。

Answer 2

这听起来很适合 LINQ to SQL。它为您提供所需的性能，并配有非常简单的强类型访问数据的方式。

Answer 3

我很少使用数据集。但是，我认为你对他们有一个错误的印象。

数据集不包含整个数据库...除非您通过Command和Adapter运行的查询返回整个数据库。如果您想要的只是少量行，则仅查询该行，这就是数据集将包含的全部内容。

如果您能够使用 NHibernate、Linq to SQL 或 Entity Framework 之类的工具，那么这可能是您的一个好方法；它为您提供了 ADO.NET 数据集的一些离线优势，而无需承担所有开销。

Answer 4

我认为你应该抽象每一层。您最终应该决定使用哪个数据库。设计和实现一切，以便您基本上可以插入您想要的任何数据存储，您不希望数据库规定您的解决方案的任何要求。

我推荐你读很多关于设计模式的书，其中一本是四人帮的书。

Answer 5

如果您只需要 1 条记录，您不想查询数据库并返回 1,000 条记录。当您查询数据库并且只需要一条记录时，请编写 SQL 以仅定位您需要的记录。

我已经研究 .Net 很长时间了，如果我是你，我会花一些时间研究实体框架、实体空间（我的偏好）、nHibernate 或某种时尚的 ORM。

它们使生活变得更加轻松，如果做得正确，您仍然可以拥有良好的松散耦合架构。

简而言之，数据集相当蹩脚，它们看起来很强大，但通常会导致架构很差。