如果有一行业务应用程序像这样分层，那么这是一个适当的分工：
数据访问
仅调用 存储过程，将DTO的属性映射到用于填充ADO.NET命令参数集合的哈希表。
仅参考SqlDataClient进行汇编。
所谓的商业逻辑
将多个结果集拆分为单独的DataTable，例如
public void ReturnNthRecordSetFromStoredProcFoo（）
传递给数据集的数据访问，例如
public void ReturnDataSet（string name）{ return（new PersonController）.GetAnotherDataSet（name）;}
将DataTable的一行映射到一个DTO
UI
所以问题，最后 - 使用这个应用程序，数据访问层是否应该假设所谓的业务层的职责合并？这不是一个两层，（几乎一个！）应用程序除了额外组装的不便之外？
其他信息：好的，我已经知道应用服务器将是一台机器，可能永远，因为它是一个低用户数的Intranet应用程序。所以我知道不要为物理上分开的应用程序层进行设计。此外，它可能只支持一个用户界面，并且如果它需要支持ASP.NET以外的其他内容则完全废弃 - 这是层/层的另一个引用原因。
答案 0 :(得分：3)
根据您的服务器负载情况，应确定物理层数。逻辑层的数量实际上更多的是个人选择。
在我们的组织中，我们使用CSLA framework。它是一个业务对象框架，致力于使丰富的数据绑定UI易于使用和维护，同时在数据层中提供灵活性。
我不会在这里深入探讨，因为你最好自己确定框架是否值得你使用，但不用说，它有自己的SafeDataReader类来解释空值，消除需要使用数据集。
它的“dataportal”（文章较旧但仍然相关）允许您轻松地将数据访问移动到自己的图层，而不需要更改代码。
DNRtv有一些视频播客，其中CSLA的设计者Rockford Lhotka展示了示例应用程序的工作原理。 Part 1和Part 2。
每个节目只有一个小时，可以帮助您确定它是否适合您使用。
答案 1 :(得分：3)
在我看来，层级之间的责任有点混乱。数据层听起来相当标准。 （“所谓的”）业务层是事情变得混乱的地方。
关于业务层的一些想法：
似乎有很多数据表示。您提到了DataTables，DataSet，数据传输对象。整个应用程序的标准方法会更好。
名称为ReturnNthRecordSetFromStoredProcFoo和ReturnDataSet的业务层方法没有意义，也没有为业务服务提供适当的抽象级别。 （也许那些只是选择不当的例子而不是申请？）
通常，业务层提供的不仅仅是DataSet传递。而不是处理映射，空值等，业务层应该专注于验证，业务规则，安全性，甚至审计（尽管有些人更喜欢在数据库中这样做）。
即使业务层只调用单个存储过程，我对业务层中的事务控制也没有任何问题。业务层应该控制事务，以便多个数据对象都可以参与同一个事务（甚至可以跨越不同的数据库）。即使现在只有一个呼叫，如果您将来需要添加更多呼叫，这将很容易，并且不会导致将事务控制改装到您的应用程序中。
我认为依赖项是正常的 - 没有从业务层引用Web.UI或SQLClient。
授权规则也行。我会扩展到包括安全性而不仅仅是授权。此外，我没有看到任何业务逻辑 - 只是好奇业务逻辑是否在存储过程中？如果我要猜测，我会说是的，因为每个业务方法只调用一个存储过程。如果是这样，那对我来说这是一个不可能的事。
我不会将业务层和数据层组合在一起。我更喜欢将业务逻辑层和数据访问层分开。考虑到在组合它们之间做出选择并试图将责任分开一点，我会倾向于后者。
然而，看到这是一个有问题的现有应用程序，我会采取更务实的观点。一切都需要成本，重要的是确定正在进行哪些更改，更改的工作量和风险是什么，更改的真实优势是什么，以及更改将如何影响测试周期。
要考虑的其他一些问题是：您想要解决的主要问题是什么？它们是否有效（例如错误，缺乏稳定性）？还是表现相关？还是建筑？或者可能与可维护性有关 - 您是否需要添加新功能但却难以找到？你有时间表或预算吗？如果您能回答其中一些问题，可能会对您有所帮助。
答案 2 :(得分：1)
我希望将您描述的业务层视为数据层类型。我希望我的数据层可以保护我不必担心空值等等。我也希望我的业务层包含更抽象的业务规则和概念。例如，如果“组”是“用户”的集合，我希望看到业务类型函数将这些用户作为高级别组的一部分进行操作。例如，可能是一个函数，它将为该组的所有成员分配权限，或允许UI级别将策略应用于作为组成员的那些用户。我不希望看到试图隐藏它们都来自数据库这一事实的函数。我希望这有用。