.net - 如何拆分数据层和业务对象层，各自的职责是什么？

Question

如果有一个像这样分层的业务应用程序，这是否是一种适当的分工:

数据访问

• 调用仅 存储过程，映射 DTO 的属性s 到用于填充 ADO.NET 命令的参数集合的哈希表。

• 仅引用 SqlDataClient 的程序集。

• 处理映射代码中空白、null 和空的含义的重要逻辑，但除此之外没有验证或其他领域特定逻辑。

所谓的业务逻辑

• 将多个结果集拆分为单独的数据表，例如

  public void ReturnNthRecordSetFromStoredProcFoo()

• 传递到数据集的数据访问，例如

  public void ReturnDataSet(字符串名称){ return (new PersonController).GetAnotherDataSet(name);

• 将 DataTable 的一行映射到一行 DTO

• 处理映射代码中 blank、null 和 empty 含义的重要逻辑。
• 持有事务对象，尽管它专门用于包装单个存储过程调用。
• 没有对 SqlDataClient 的引用，所以它不能使用 SqlDataReaders 来填充 DTO
• 没有引用 System.Web.UI
• 授权规则，但除此之外没有特定领域的逻辑。

用户界面

• DTO 到 ASP.NET 表单的 2 种数据绑定(bind)方式。
• 控件属性的验证 - 通常不直接针对 DTO 进行验证
• “集合”通过将数据集绑定(bind)到网格来导航。事实上，尝试对集合做任何事情都需要 UI 遍历 DataTables 中的 DataRows 并知道适当的列名是什么(通常与 DTO 只是有点相似)

那么最后的问题是——对于这个应用程序，数据访问层是否应该合并所谓的业务层的职责？这不是已经是两层了吗，(几乎一个!)应用程序除了额外组装的不便？

附加信息:好的，我已经知道应用程序服务器将是一台机器，可能永远是一台机器，因为它是一个低用户数的 Intranet 应用程序。所以我知道不要为物理上分离的应用程序层进行设计。此外，它可能只支持一个 UI，如果它需要支持 ASP.NET 以外的其他东西，它可能会被完全废弃——另一个经常被引用的层/层的原因。

Answer 1

在我看来，层级之间的责任有点困惑。数据层听起来相当标准。 (“所谓的”)业务层是事情变得困惑的地方。

关于业务层的一些思考:

• 似乎有很多数据表示。你提到了数据表、数据集、数据传输对象。整个应用程序的标准方法会更好。

• 名称为 ReturnNthRecordSetFromStoredProcFoo 和 ReturnDataSet 的业务层方法没有意义，并且没有为业务服务提供适当的抽象级别。 (也许这些只是选择不当的示例，而不是来自应用程序？)

• 通常，业务层提供的不仅仅是数据集传递。业务层不应处理映射、空值等，而应专注于验证、业务规则、安全性，甚至可能是审计(尽管有些人更喜欢在数据库中这样做)。

• 虽然业务层只是调用一个存储过程，但我对业务层的事务控制没有问题。业务层应该控制事务，以便多个数据对象都可以参与同一个事务(甚至可以跨不同的数据库)。即使现在只有一个调用，如果您将来需要添加更多调用，这将很容易，并且不会导致在您的应用程序中改进事务控制。

• 我认为依赖关系没问题——没有从业务层引用 Web.UI 或 SQLClient。

• 授权规则也OK。我会扩展到包括安全性而不仅仅是授权。此外，我在任何地方都看不到任何业务逻辑——只是想知道业务逻辑是否在存储过程中？如果我要猜的话，我会说是，因为每个业务方法只调用一个存储过程。如果是这样，那对我来说是一个很大的禁忌。

我不会将业务层和数据层结合起来。我更喜欢将业务逻辑层和数据访问层分开。如果要在合并它们和尝试将职责进一步分离之间做出选择，我会倾向于后者。

但是，鉴于这是一个存在问题的现有应用程序，我会采取更务实的观点。一切都是有代价的，重要的是要确定正在进行的更改、更改的工作量和风险、更改的真正好处是什么，以及更改将如何影响测试周期。

其他一些需要考虑的问题是:您想解决的主要问题是什么？它们是否起作用(例如错误、缺乏稳定性)？还是性能相关？或者它是建筑的？或者可能与可维护性有关——您是否需要添加新功能但发现很难？你有时间框架或预算吗？如果您能回答其中一些问题，它可能会帮助您找到方向。