c# - 不使用数据集的N层体系结构(数据集听起来对性能不利)

Question

我阅读了有关n层架构的书籍，文章，教程和所有类似内容，并且我尝试应用著名的3层（DAL，BLL，PL），而我刚进入游戏，实际上我已经阅读很多有关将整个数据库加载到内存中（数据集所做的操作）有多糟糕的信息，特别是在我需要查看有关必须从5个表或某些内容中检索到的项目的详细信息时，很多，我只想要一个记录！唯一的情况是我需要很多记录一次不会很多，它将检索类似这样的非常简单的信息（ID，名称，地址）！

您是否认为找到另一种无需数据集的DAL和BLL更好的方法？还是数据集更好？如果数据集的性能不佳等等，您有什么资料可以教我该怎么做？

Answer 1

大部分被说成是可靠的建议。我同意，如果您打算投入时间来构建N-Tier应用程序，则应该考虑研究ORM解决方案。如果您基于.NET技术构建，则EF4是构建DAL的一种非常好的方法。

您对DAL / BLL应该返回什么的理解上有一定的困惑。现在，.NET 3和4中的DataSet有点过时了，尽管并不罕见。构建DAL时，您应该阅读Repository设计模式。根据实现的不同，您的存储库通常会返回通用List<T> or IQueryable<T>。 IQueryable是我的首选，但是，有人认为它模糊了BLL和DAL之间的界限。

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

因此，例如：

Repository<TEntity> : IRepository<TEntity> where TEntity : ITrackable

要查看设计DAL的绝佳方法，请查看nCommon。
Tony Sneed有一个很棒的博客系列，介绍如何将Entity Framework与POCO结合使用：
http://blog.tonysneed.com/2010/02/19/trackable-dtos-taking-n-tier-a-step-further-with-ef4/

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

我的建议是主观的，不应视为正确或不正确。我不知道您的申请要求。如果您可以使用简单的数据集和sqldatareader更快地完成一些代码，则投资回报可能对您来说更大。如果您希望构建可维护的设计，请像其他人建议的那样，花额外的时间阅读有关EF4和N层架构模式的信息。



[编辑]

为了回应您在下面的评论，我想我可以分享一些我在学习体系结构中发现的宝贵资源。

首先，准备好投入无数个小时的阅读和重新阅读。利用您当前的知识并坚持不懈地练习，运用所学知识。要实现的最重要的事情是：您的设计将永远不会是完美的，因为没有这样的事情，仅仅因为您应用模式并不一定会使它最佳。

拥有自己的个人项目对于在OOP中取得进展至关重要。在马尔科姆·格拉德威尔（Malcolm Gladwell）的书《离群值》中，他认为，掌握某项东西平均需要10,000个小时的练习。因此，请继续编码和学习。 :)

您可以挑选的最好的书之一是Head First - Design Patterns。这是一本非常出色的OOD入门书籍，它改变了您对代码的思考方式。我记得读过几章后立刻意识到：“哇！我一直在写这样的代码，但从来不知道它有名字！”它帮助我意识到熟悉的设计问题有多深。他们有共同的解决方案，以及与其他开发人员进行交流的重要性。那本书会（以一种很好的方式）严重地打败你。

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

有许多出色的免费在线资源，例如Microsoft的Application Architecture Guide。学习技巧的一些最佳方法就是阅读博客。

对于Entity Framework，很难击败Julia Lerman的Programming 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）一起使用。

当您开始涉及分层体系结构时，您的Repository负责与ORM或数据库进行通信，并将结果返回给BLL。例如，一个基本示例如下所示：

using (var repository = new Repository<User>()) { User user = repository.Where(u => u.UserId == 1).SingleOrDefault(); }

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

希望这可以帮助。



[编辑2]

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

通常，在ORM所在的基础结构层中，您将返回通用List<T>或IQueryable<T>，其中T代表您的对象。它是实体对象还是POCO取决于您。 POCO只是代表您的数据的一类，但是它不仅仅是大量的获取器和设置器。它至少应包含验证。阅读有关贫血领域模型以及如何避免它们的内容。

在包含业务逻辑的域层中，根据要实现的松散耦合程度，您将返回List<T>，BindingList<T>，或者将使用映射技术来返回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;
}

}

它们只是吸气剂和吸气剂的袋子。您的POCO应该能够轻松地映射到它们，并且有一个出色的软件可以简化此过程：AutoMapper。它们不必表示数据库或POCO对象中的确切表，但可以包含它们的几个部分，如上所示。

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

这个对象没有确切的名称，但是我继续称它为响应传输对象，它由Microsoft企业库中的List<IDto>，ValidationResults以及其他我需要知道的内容组成。

这要消耗很多信息。学习NLayer开发时，请像对待每一层一样将其分解。一次学习一件事，写下每个突然出现的问题。确保找出那些答案。