如果有一个像这样分层的业务应用程序，这是否是一个适当的分工：
数据访问
所谓的业务逻辑
-
将多个结果集拆分为单独的数据表，例如
public void ReturnNthRecordSetFromStoredProcFoo()
-
传递到数据集的数据访问，例如
公共无效ReturnDataSet（字符串名称）{
return (new PersonController).GetAnotherDataSet(name);}
-
将 DataTable 的一行映射到一个 DTO s
- 处理映射代码中空白、空和空的含义的逻辑。
- 保存事务对象，尽管它专门用于包装单个存储过程调用。
- 没有对 SqlDataClient 的引用，因此无法使用 SqlDataReaders 来填充 DTO
- 没有对 System.Web.UI
- 授权规则的引用，但没有域特定的逻辑。
UI
- DTO 到 ASP.NET 表单的 2 种方式数据绑定。
- 控件属性的验证 - 通常不直接针对 DTO 进行验证
- 通过将数据集绑定到网格来导航“集合”。 事实上，尝试对集合执行任何操作都需要 UI 迭代 DataTable 中的 DataRow，并知道适当的列名称是什么（通常与 DTO 有点相似）
所以问题是，最后 -在这个应用程序中，数据访问层是否应该承担所谓业务层的职责进行合并？除了额外组装的不便之外，这不是已经是一个两层（几乎是一层！）的应用程序了吗？
附加信息：好的，我已经知道应用程序服务器将是一台机器，可能永远是一台机器，因为它是一个低用户数的 Intranet 应用程序。 所以我知道不要为物理上独立的应用程序层进行设计。 此外，它可能只支持一个 UI，如果需要支持 ASP.NET 以外的其他内容，它可能会被完全废弃——这是层/层的另一个经常引用的原因。
If there was a line of business application layered like this, would this be an appropriate division of labor :
Data Access
-
Invokes only stored procedures, maps properties of DTOs to a hash tablse which are used to populate ADO.NET command's parameter collections.
-
Only assembly with reference to SqlDataClient.
- Significant logic dealing with what means blank, null, and empty in the mapping code, but other wise no validation or other domain specific logic.
So-Called Business Logic
-
splits multiple result sets into individual DataTables, e.g.
public void ReturnNthRecordSetFromStoredProcFoo()
-
pass through to data access for datasets, e.g.
public void ReturnDataSet(string name){
return (new PersonController).GetAnotherDataSet(name);}
-
maps one row of a DataTable to one DTOs
- Significant logic dealing with what means blank, null, and empty in the mapping code.
- Holds transaction object, although it is used exclusively to wrap single stored procedure calls.
- Doesn't have a reference to SqlDataClient, so it can't use SqlDataReaders to fill DTOs
- No reference to System.Web.UI
- Authorization rules, but otherwise no domain specific logic.
UI
- 2 way data binding of DTOs to ASP.NET forms.
- Validation of properties of controls- generally no validation directly against DTOs
- "Collections" are navigated by binding DataSets to grids. In fact attempting to do anything with collections requires the UI to iterate over DataRows in DataTables and know what the appropriate column names are (which are generally only kind-of-similar to the DTOs)
So the question, finally-- with this application, should the Data Access Layer assume the the duties of the so-called business layer be merged? Isn't this already a two layer, (almost one!) application except for the inconvenience of an extra assembly?
Additional info: Ok, I already know that the application server will be one machine, probably forever, since it is an low-user-count intranet app. So I know not to design for physically separate application tiers. Also, it will probably only support one UI and be entirely scrapped if it ever need to support something other than ASP.NET-- another oft quoted reason for tiers/layers.
发布评论
评论（3）
在我看来，各层之间的责任有点混乱。 数据层听起来相当标准。 （“所谓的”）业务层是事情变得混乱的地方。
关于业务层的一些想法：
似乎有很多数据表示。 您提到了数据表、数据集、数据传输对象。 跨整个应用程序的标准方法会更好。
名称为 ReturnNthRecordSetFromStoredProcFoo 和 ReturnDataSet 的业务层方法没有意义，并且不能为业务服务提供适当的抽象级别。 （也许这些只是选择不当的示例，而不是来自应用程序？）
通常，业务层提供的不仅仅是数据集传递。 业务层不应该处理映射、空值等，而应该专注于验证、业务规则、安全性，甚至可能是审核（尽管有些人更喜欢在数据库中执行此操作）。
尽管业务层只调用单个存储过程，但我对业务层的事务控制没有任何问题。 业务层应该控制事务，以便多个数据对象都可以参与同一个事务（甚至可以跨不同的数据库）。 尽管现在只有一个调用，但如果您将来需要添加更多调用，这将很容易，并且不会导致将事务控制改造到您的应用程序中。
我认为依赖关系正常 - 没有从业务层引用 Web.UI 或 SQLClient。
授权规则也OK。 我将扩展到包括安全性而不仅仅是授权。 另外，我在任何地方都没有看到任何业务逻辑——只是好奇业务逻辑是否在存储过程中？ 如果我要猜测，我会说是，因为每个业务方法仅调用一个存储过程。 如果是这样，那么这对我来说是一个很大的禁忌。
我不会将业务层和数据层结合起来。 我更喜欢将业务逻辑层和数据访问层分开。 如果要在将它们结合起来和尝试将责任进一步分离之间做出选择，我会倾向于后者。
然而，鉴于这是一个存在问题的现有应用程序，我会采取更务实的观点。 一切都是有成本的，重要的是要确定正在做出哪些改变，改变的努力和风险是什么，改变的真正好处是什么，以及改变将如何影响测试周期。
其他需要考虑的问题是：您想要解决的主要问题是什么？ 它们是否有效（例如错误、缺乏稳定性）？ 还是与性能有关？ 或者它是建筑学的？ 或者可能与可维护性有关——您是否需要添加新功能但发现这很困难？ 您有时间范围或预算吗？ 如果您能回答其中一些问题，可能会对您有所帮助。
It sounds to me that the responsibility between tiers is a little muddled. The data layer sounds fairly standard. The ("so-called") business layer is the place where things get muddled.
Some thoughts on the Business Layer:
There seems to be a lot of data representations. You mention DataTables, DataSets, Data Transfer Objects. A standard approach across the entire application would be better.
Business layer methods with names like ReturnNthRecordSetFromStoredProcFoo and ReturnDataSet are not meaningful and do not provide an appropriate level of abstraction for business services. (Maybe those were just poorly chosen examples not from the application?)
Typically a business layer would provide more than a DataSet pass through. Instead of dealing with mappings, nulls etc. the business layer should focus on validation, business rules, security, and maybe even auditing (although some prefer to do that in the database).
Even though the business layer is only invoking a single stored procedure, I have no problem with the transaction control in the business layer. Business layer should control the transaction so that multiple data objects can all participate in the same transaction (it could even be across different databases). Even though there is only one call now, if you ever need to add more calls in the future this will be easy and will not result in retrofitting transaction control into your application.
I think the dependencies are OK -- no reference to the Web.UI or SQLClient from the business layer.
Authorization rules are also OK. I would expand to include Security and not just authorization. Also, I don't see any business logic anywhere -- just curious if the business logic is in the stored procedures? If I was going to guess, I would say yes given that each business method invokes only one stored procedure. If so, then that is a big no no for me.
I would not combine the business and data layers. I prefer to keep the business logic layer and the data access layer separate. Given a choice between combining them and trying to separate the responsibilities a little more I would lean toward the latter.
However, seeing as though this is an existing application with issues I would take a more pragmatic point of view. Everything comes with a cost and it is important to determine what changes are being made, what is the effort and risk of the changes, what is the real benefit of the changes, and how the changes will impact on the testing cycle.
Some other questions to think about are: what are the main issues you want to address? Are they functional (e.g. bugs, lack of stability)? Or performance related? Or is it architectural? Or perhaps related to maintainability -- do you need to add new functionality but are finding it difficult? Do you have a time frame or a budget? If you can answer some of those questions it might help guide you.
应根据您的服务器负载确定物理层的数量。 逻辑层的数量实际上更多是个人选择。
在我们的组织中，我们使用 CSLA 框架。 它是一个业务对象框架，致力于使丰富的数据绑定 UI 易于使用和维护，同时提供数据层的灵活性。
我不会在这里深入讨论，因为您最好自己确定该框架是否值得您使用，但不用说，它有自己的 SafeDataReader 类，该类可以处理空值，从而无需使用数据集。
它的“数据门户”（文章较旧，但仍然相关）允许您轻松地将数据访问移至其自己的层，只需很少的努力，并且无需更改代码。
DNRtv 有一些视频播客，其中 CSLA 的设计者 Rockford Lhotka 展示了示例应用程序的工作原理。 第 1 部分 和 第 2 部分。
这些节目每次只有一个小时，可能可以帮助您决定它是否适合您使用。
Depending on your server load should determine the number of physical layers. The number of logical layers is really more of a personal choice.
In our organization we use the CSLA framework. It is a business object framework that strives to make rich, databound UIs simple to use and maintain, while giving flexibility in the data layer.
I wont go into too much depth here as it would be better for you to determine for yourself if the framework is worth it for you to use, but needless to say, it has its own SafeDataReader class which accounts for nulls, eliminating the need to use datasets.
Its "dataportal" (article is older but still relevant) allows you to easily move the data access to its own layer with very little effort, and no change of code.
DNRtv has a few video pod casts in which the designer of CSLA, Rockford Lhotka, shows the workings of the sample application. Part 1 and Part 2.
The shows are only an hour each and can probably help you decide if its the right thing for you to use.
我希望看到您所描述的业务层作为数据层类型的内容。 我希望我的数据层能让我不必担心空值之类的事情。 我还希望我的业务层包含更抽象的业务规则和概念。 例如，如果“组”是“用户”的集合，我希望看到业务类型函数来将这些用户作为高级别组的一部分进行操作。 例如，可能有一个函数可以向该组的所有成员分配权限，或者允许 UI 级别将策略应用于作为组成员的这些用户。 我不希望看到函数试图隐藏它们都来自数据库的事实。 我希望这是有帮助的。
I would expect to see what you describe as your business layer as data layer type stuff. I'd hope that my data layer would shield me from having to worry about nulls and such things. I'd also hope that my business layer would contain business rules and concepts that are more abstract. For example if a "Group" is a collection of "User"s I'd like to see business type functions to manipulate those Users as part of a Group at a high level. For example maybe a function that would assign permissions to all the members of that group or allow the UI level to apply policies to those users as members of a group. I wouldn't hope to see functions that try to hide the fact that they all came from a database. I hope this is helpful.