ASP.NET 分层设计答案

【问题标题】：ASP.NET layered design [closed]ASP.NET 分层设计
【发布时间】：2012-07-19 11:17:50
【问题描述】：

我从 MSDN 阅读了以下文章：http://msdn.microsoft.com/en-us/library/aa581779

它谈到了创建数据层、业务逻辑层和表示层，以及具有 getProductsDAL()、getProductsBLL() 等命名约定，甚至将它们分离到类库中。

我的问题是：如果不使用 .NET 数据集，即如果您自己完成所有逻辑，开发人员会遵循这种方法吗？有一个名为 getProducts 的函数，它使用连接对象连接到数据库，然后使用 SQLDataReader 循环遍历结果集并在页面上显示结果。我正在考虑将这样的函数拆分为层。

【问题讨论】：

遗憾的是反对票，这是许多开发人员在某个阶段提出的问题。阅读这个：stackoverflow.com/questions/1182303/… 和这个en.wikipedia.org/wiki/Multitier_architecture

标签： asp.net vb.net design-patterns

【解决方案1】：

如果您打算按照自己的方式行事：
您的数据层将包含打开连接、执行查询/存储过程并返回数据集或数据表的方法。该层不接收上层的连接信息，只返回每个方法的查询结果。连接在此级别实例化。

您的业务逻辑层包含每个调用一个或多个数据层方法的方法。示例：添加新用户也意味着为该用户设置权限，因此 DL.InsertUser(params...) 和 DL.SetPermissions(int Userid, List permissions) 由 BL.AddNewUser(params...) 调用。此 BL 方法还可以调用另一个 DL 方法，该方法获取默认权限列表以分配新用户

您的 UI 层将使用所有适当的新用户详细信息调用 BL.AddNewUser(params...)

【讨论】：

您认为这是一种好的做法吗？我继承了一个 ASP.NET 应用程序，该应用程序在类中具有低内聚和紧密耦合。我正在尝试遵循结构化的方法来进行未来的发展。这是你会遵循的模式吗？
我已经构建了具有高内聚和松耦合的系统。只需在选择正确的类中的方法放置时保持一致，并防止类服务于多种用途。
表现层调用业务逻辑层，业务逻辑层调用数据访问层？我正在考虑从数据层返回 SQLDataReaders，稍后可以在业务逻辑中循环。然后，业务逻辑层可以返回一个表格以放在页面上。
我已经准备好将这个标记为已回答。如果需要，你会在数据访问层和业务逻辑层创建接口吗？
调用：UI > BL > DL。结果：DL > BL > UI。易于遵循的模式：始终从您的 DL 返回数据集。即使它们是空的（应该几乎永远不会！）将 BL 比 DL 绑定到接口更有意义。你需要接口吗？多种类型/数量的参数意味着将 DL 绑定到一个接口会有点摇尾巴。