3

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

数据访问

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

  • 仅参考 SqlDataClient 的程序集。

  • 处理映射代码中的空白、null 和空的含义的重要逻辑，但其他情况下没有验证或其他特定于域的逻辑。

所谓的业务逻辑

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

    公共无效 ReturnNthRecordSetFromStoredProcFoo()

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

    public void ReturnDataSet(string name){ return (new PersonController).GetAnotherDataSet(name);}

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

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

用户界面

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

所以最后的问题是——对于这个应用程序，数据访问层是否应该承担所谓的业务层的职责？ 除了额外组装带来的不便之外，这不是已经是两层（几乎是一层！）应用程序了吗？

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

4

3 回答 3

3

应根据您的服务器负载确定物理层的数量。逻辑层的数量实际上更多的是个人选择。

在我们的组织中，我们使用CSLA 框架。它是一个业务对象框架，致力于使丰富的数据绑定 UI 易于使用和维护，同时在数据层提供灵活性。

我不会在这里深入探讨，因为您最好自己确定该框架是否值得您使用，但不用说，它有自己的 SafeDataReader 类来解释空值，无需使用数据集。

它的“数据门户”（文章较旧但仍然相关）允许您轻松地将数据访问移动到它自己的层，只需很少的努力，并且无需更改代码。

DNRtv有一些视频播客，其中 CSLA 的设计师 Rockford Lhotka 展示了示例应用程序的工作原理。第 1部分和第 2 部分。

每个节目只有一个小时，可能可以帮助您确定它是否适合您使用。

于 2009-07-31T02:48:24.197 回答
3

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

关于业务层的一些想法：

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

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

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

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

  • 我认为依赖关系是好的——业务层没有对 Web.UI 或 SQLClient 的引用。

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


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

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

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

于 2009-07-31T04:39:04.570 回答
1

我希望看到您将业务层描述为数据层类型的东西。我希望我的数据层能够让我不必担心空值和此类事情。我还希望我的业务层包含更抽象的业务规则和概念。例如，如果“组”是“用户”的集合，我希望看到业务类型函数将这些用户作为高级别组的一部分进行操作。例如，一个函数可能会为该组的所有成员分配权限，或者允许 UI 级别将策略应用于作为组成员的那些用户。我不希望看到试图隐藏它们都来自数据库的事实的函数。我希望这是有帮助的。

于 2009-07-31T02:39:18.517 回答