C# 设计n层应用程序时的困惑

我一直很难理解如何将我的程序划分为三层（BLL、DAL、UI）的n层应用程序。在这个问题上我太糊涂了，不知道从哪里开始。我看过视频、文章和应用程序示例，但我发现很难理解。从一个例子到下一个例子似乎缺乏一致性。有什么资源我可以看，这是非常彻底的主题

---

作为参考，我是一名C#NET入门级开发人员，这是不是一个太大的话题，现在还不能解决？我完全理解这个概念，但是我不知道如何很好地实现它。

你应该读像这样的书

但是如果你是C#入门级开发人员（而不是同时是高级Java开发人员），那么它们可能太难了

---

一些概述和基本理解你可以获得或搜索一些关于这个主题的简短而简单的文章。

你应该阅读以下书籍

但是如果你是C#入门级开发人员（而不是同时是高级Java开发人员），那么它们可能太难了

---

一些概述和基本理解，你可以得到或搜索一些关于这一主题的简单易懂的文章。对于初学者来说，考虑三层设计是很好的，但要知道，在实践中，似乎会有比3层更多的层。但是，基本上有3层

表示层 您构建的任何应用程序都将具有某种表示层。它可能实际上是表示，也可能只是返回客户端所需数据的层（例如web服务响应、HTML/JavaScript中的客户端UI等）。通常，您会有一些表示客户端数据的类，通常称为ViewModel或表示模型。这里的关键是数据特定于您所呈现的视图。例如，订单历史记录表单只显示订单号、订单日期和总成本。在此特定视图中，您可能不需要知道用户名、每行项目的成本、发货数量、税额、发货方式等。关于ViewModels应该如何工作以及它们是否必要，存在很多争论。这取决于你的应用程序。关键是，如果采用这种方法，ViewModels只是轻量级的类，用于保存视图/页面使用的数据

业务逻辑/域层 这一层通常可以分成几块。它们可能包括以下内容：

• 域对象或业务对象-这些是业务逻辑的对象表示。在域驱动设计（DDD）和几乎所有其他编程范式中，这是您的业务对象应该驻留的地方。它们可能是表示客户、订单、帐户等的类。这里的关键是，它们是在应用程序上下文中有意义的数据表示。它们可能与数据库中的数据不相似，也可能与向用户显示的数据不相似，但在应用程序中，它们的结构是合理的
• 存储库-这些是“集合”（我用引号表示，因为它们实际上可能不是集合），它们隐藏了数据层的复杂性，并返回了域对象的副本。这里的想法是，如果需要Order对象，可以向存储库请求。例如，OrderRepository.FindByDateRange（startDate，endDate）。同样，这里的关键是您的业务层不必直接访问数据；存储库掩盖了这种复杂性，还允许您更轻松地更改数据源，如数据库、xml、缓存等
• Helpers或业务/域逻辑-这些通常是位于业务逻辑层中的类，用于处理特定于业务的事情。它们可能包括验证、计算、数据操作等。这里的关键是它们处理业务层数据，并根据您的业务需求对其执行操作。例如，您可能需要确保所有订单至少有3个行项目可以免费发货。这是一个业务规则，应该在您的业务层中实施

数据层 数据层是与数据存储通信的实际代码。它可以是ADO.NET或对象关系映射器，如实体框架、nHibernate或其他。这是任何SQL或其他数据查询都将驻留的地方（当然，T-SQL应该尽可能多地位于数据库中，但依应用程序的类型而定，这是可以原谅的，IMO）。这里的关键是，您的业务层和表示层不应该知道数据实际来自何处，只有他们以预期的格式接收。此数据层是返回该信息的层。通常，数据层将查询数据存储并将数据放入某种类型的类（有时称为数据实体或数据传输对象）。存储库使用它们来生成上述业务对象

额外资源 在上面的层中，您可能还有一些映射类，例如，它们可以帮助从数据对象创建业务对象。像AutoMapper这样的项目有助于实现这一点，尽管我承认我没有这方面的任何经验

了解多态性和接口是个好主意。抽象对于这种层分离变得越来越重要。抽象可以让存储库从数据库或完全不同的源获取数据，但业务层不应该关心哪个。业务层所需要的只是以预期的格式获取一些数据，而不必关心从何处获取数据。我会认真考虑以下内容：坚实的设计原则、设计模式（至少是存储库、适配器、工厂）、依赖性反转原理（不一定是控制框架的倒置或任何东西），至少在您理解之前