在 N 层架构中实现数据库功能对象？

Question

我正在向我们的网站添加功能，该功能使用 MSMQ 异步执行长时间运行的进程。然而，执行此同步意味着我们需要在用户的请求完成时通知他们。使用命令模式，我创建了一个名为 INotify 的接口*，并将其组合到消息类中，因此消息处理类可以简单地在消息的 INotify 对象上调用 GiveNotice()。第一个实现，EmailNotify，比预期的更困难，因为我惊讶地发现 MailMessage 不可序列化，但还是成功了。

现在我正在开发一个新的具体通知程序 DBNotify，它将调用某种 SP 并更新主事务数据库中的状态。我很困惑，因为我想重用我们已经创建的 DAL 架构，但 INotify 是 Model 项目的成员，它比 DAL 更基础。

我们的层次结构如下所示： 常见>型号> DAL> BAL

以下是有关层级的更多详细信息。请记住，我继承了这个： Common 负责应用程序中许多地方使用的所有“实用”功能，例如访问配置设置、解析字符串、非业务相关功能。

模型是业务对象，有些人称之为数据传输对象，即 getter 和 setter 的集合。我在这一层添加了一些“智能”，但仅限于该对象内部的业务规则，例如“项目的名称必须以字母数字字符开头”。

DAL 是数据访问层，理论上，这里发生的只是模型对象移入和移出数据库。

BAL是业务层；理论上，管理对象交互的业务规则是强制执行的（即“表单必须至少有两个项目。”）。

因此，INotify 接口被定义为一个抽象，以允许通知方法独立变化（即电子邮件、TXT、twitter 等）。它是系统的基础，因此我在模型层创建了它，该层独立于 DAL 层。但是，我正在创建 INotify 的新具体实现，其通知方法是调用数据库中的 SP。

是否有其他人处理过旨在与数据库交互的业务对象？您如何将其放置在 N 层架构中？

在您告诉我使用 Linq to Sql 之前，非常感谢。这不是一个技术问题（我该怎么做），这是一个设计问题（我应该怎么做）。

我认为有一个 StackExchange 站点更专注于这些与语言无关的设计问题，所以我将把它复制到那里。

Answer 1

也许这并不是你问题的真正答案，但仍然值得思考。

我不同意您将数据访问放在组件层次结构中的位置。我不会把它放在两个功能域层之间。甚至不“高于”单域模型类。数据访问或持久性不是任何域类所关心的问题。这应该只是可以对他们做的事情，而不是他们所做的事情。

尽管我开始编写诸如 TClient.Save 和 TClient.Load 之类的代码，但我现在得出的结论是，不是客户端决定需要保存它，但用户交互决定何时需要域实例的数据并因此应加载，以及何时应保留客户端的数据（如果有的话）。因此，我现在是诸如 DataStore.Load(ClientInstance) 和 DataStore.Save(ClientInstance) 之类的编码（在 GUI 中，更具体地说是 GUI 中的控制器）的支持者。然后由数据访问层来决定如何做到这一点。它可以使用 C# 中的反射或 Delphi 中的新 RTTI 来迭代所有客户端的属性，以便将它们发送到数据库。

虽然分层是一个非常好的概念，可以通过简单地遵循“可以向下调用但不能向上调用”来分离关注点并防止您将东西放得到处都是，但在解决日志记录、异常处理、通知等问题时，它并没有多大帮助。以及所有其他组件/层都需要的其他有趣的横切关注点。

此外，公共层，因为它是一个实用层，应该真正可供所有其他层访问。

总而言之（我保留了简单域类、模型和跨类业务规则、BAL 之间的区别）：

+---+   +-------------+
| C |<--| Data Access |<--------------------------+
| o |   +-------------+                           |
| m |         |                                   |
| m |         |                                   |
| o |         v                                   |
| n |   +-------------+   +----------------+   +-----+
|   |<--| Model       +<--| Cross class    |<--| GUI |
|   |   +-------------+   | business rules |   |     |
|   |                     |                |   |     |
|   |<--------------------|                |   |     |
|   |                     +----------------+   |     |
|   |                                          |     |
|   |<-----------------------------------------|     |
+---+                                          +-----+

调用数据库的 INotify 实现当前位于模型中，该实现位于模型中。上图不会调用数据访问层本身，它只是由数据访问层调用，或者更确切地说是询问。

真正的问题是 INotify 是否应该在“模型”中，域层的一部分，或者它是否应该是一个通用接口，并且应该有一个可以从域和 GUI 访问的单独的“通知”层/组件。这个新组件不仅可以关注通知，还可以关注许多其他横切问题，例如日志记录。它至少可以以某种回调方式访问公共（当然）和数据访问组件以及 GUI。

在下图中，我尝试将其可视化，但我不太擅长可视化，并且总是对那些讨厌的横切刀遇到问题。这就是为什么没有从域层到横切关注点的调用箭头，尽管域层当然应该能够访问例如“Logger”接口。也许我试图努力区分公共组件和横切组件，并且可以提出将它们放在一起的论点，并将它们可视化为“实用程序”层/组件中的单独块。

        +--------------------------------------------+
  +-----| Cross cutting concerns                     |
  |     +--------------------------------------------+
  v           v^                                    ^
+---+   +-------------+                             |
| C |<--| Data Access |<--------------------------+ |
| o |   +-------------+                           | |
| m |         |                                   | |
| m |         |                                   | |
| o |         v                                   | v
| n |   +-------------+   +----------------+   +-----+
|   |<--| Model       +<--| Cross class    |<--| GUI |
|   |   +-------------+   | business rules |   |     |
|   |                     |                |   |     |
|   |<--------------------|                |   |     |
|   |                     +----------------+   |     |
|   |                                          |     |
|   |<-----------------------------------------|     |
+---+                                          +-----+

Answer 2

仅仅因为您的 INotify 接口位于模型层中，并不意味着所有具体实现都需要在那里。它应该是一个接口——接口的目的是实现抽象——而不是基类——基类的目的是实现共享功能。因此，在任何层中只要有这种类型的属性或参数，就应该将其声明为 INotify。在您的 BAL（您是指 BLL，业务逻辑层吗？）中，您将决定 INotify 的这些实例使用的具体类型。根据通知的复杂程度，您可以在 BLL 中定义具体实现，并让它使用 DAL 中的辅助类来实际执行对存储过程的调用，或者您可以直接在 DAL 中将其定义为类，因为它与数据库交互；这实际上是根据班级负责的程度做出的判断；无论哪种方式，它都应该可以在顶层访问。

是否有其他人处理过旨在与数据库交互的业务对象？您如何将其放置在 N 层架构中？

您的项目的结构方式，听起来每一层的逻辑职责是：

常见：
共享实用程序方法，不依赖于项目中的任何其他内容
型号：
定义系统中实体的结构，也称为 DTO 或数据传输对象，这意味着它们可以在层之间传输。他们所做的只是存储您的数据并执行基本验证。
达尔：
负责从模型层创建类的实例，并根据存储在存储库（例如数据库）中的值设置属性。还负责跟踪模型实体的更改，并将这些更改保存（持久化）回存储库。
BAL/BLL：
使用其他层中定义的类来实现有用的功能，并验证是否遵循业务需求。

您可以使用多种技术来实现这一目标，即使使用相同的技术，您的具体实施也会根据您的工作方式而有所不同。像 Linq2Sql 或开箱即用的实体框架之类的东西会模糊模型和 DAL 之间的界限；他们想在同一个项目中定义两者。然而，实体框架更加灵活，通过一些工作，您可以将实体模型和“上下文”（使用实体框架术语）的定义拆分为单独的项目，“上下文”最终负责 DAL 组件。您可以编辑 T4 模板或在线查找将从实体模型生成实体和上下文类定义的模板，以支持存储库和工作单元设计模式，在这种模式中您从不直接引用实体上下文，而是让它实现 IRepository 接口，这使您的代码更易于测试。我个人从未使用过 NHibernate，但我的理解是它能够做同样的事情（并且可以说目前可能做得更好）。

Answer 3

如果您的模型类是您的 DTO（有些人可能称之为数据结构或数据类型），那么它们应该（可能）位于“跨”您的其他层并为所有其他层所知。

根据您所说的，您可能有一个位于 BAL 中的 MessageProcessing 类，并从 BAL 或 DAL 的其他部分接收消息，然后通知正在侦听的任何人（UI 或 BAL 的其他感兴趣的成员）。

Answer 4

如果数据实体是 POCO，您可以在项目中使用它们。否则我会像你一样创建单独的模型。但请务必将它们放在单独的程序集中（而不是在 DataAccess 项目中），

恕我直言，人们过度使用层。大多数应用程序不需要很多层。我当前的客户的所有应用程序都采用了与您类似的架构。问题是只有数据访问层和表示层有逻辑，所有其他层只是从下层获取数据，转换它，然后将其发送到上层。

我做的第一件事就是告诉他们废弃所有层，而是使用类似这样的东西（需要 IoC 容器）：

• 核心（包含通过 orm 的业务规则和数据访问）
• 规范（分离的接口模式。包含服务接口和模型）
• 用户 界面（可能是 Web 服务、winforms、webapp）

适用于大多数应用程序的 。如果您发现核心增长并变得太大而无法处理，您可以将其拆分而不会影响任何用户界面。

您已经在使用 ORM 并且是否考虑过使用验证块（FluentValidation 或 DataAnnotations）进行验证？可以轻松验证所有层的模型。

Answer 5

在许多层中使用的类让我很担心。

特别是当它们也与数据模型/基础/层相关联时。

一旦这些类发生变化，您可能会在所有层中重新编码。换句话说，你错过了抽象的有益效果。

也就是说，维护转换代码（从一层到另一层）也不是很有趣，但通常工作量较少。

中间的解决方案可能是使用接口/角色：为每个层定义对象应扮演的接口/角色，并使用该接口传递到该层。然后，（共享）类应该实现一个角色（或多个角色）。这将提供一个更松散耦合的系统。

我从这个关于 DCI（数据、协作）的简洁讲座中学到了很多东西和交互）

Answer 6

感谢大家的意见，这里有一些我计划实施的改进想法，尽管没有一个直接回答我提出的问题。

我将其交叉发布给程序员，我认为此类问题可能真正属于该问题，并得到了一些有用的想法。如果您有兴趣，该主题在这里：
程序员线程关于这个问题。诚然，我在发帖时根据自己的研究添加了依赖注入的“提示”，所以问题可能更清楚了。

这是一个伟大且乐于助人的社区，我很自豪能够参与其中。