没有如下 BLL（业务逻辑层）的ASP.Net 2.0应用程序是否“可以接受” ？
- SQL Server 数据存储和存储过程
- 连接到存储过程的数据链路层（强类型表适配器）
- 带有代码的表示层 ASPX 页面和用于直接连接到 DLL 的 ObjectDataSource
即使业务逻辑在演示文稿的代码中完全可验证，BLL 是否总是更可取？不使用 BLL 的潜在缺点是什么？
问问题
2175 次
5 回答
4
只要你明白后果是可以接受的。您拥有 BLL 的主要原因是在整个应用程序的其他地方重用该逻辑。
如果您在演示代码中拥有所有这些验证逻辑，那么您确实很难在应用程序的其他地方重用。
于 2008-08-07T02:48:48.690 回答
1
像其他一切一样，它是环境的，取决于系统的使用。你需要问自己的问题是：
- 会不会积极开发
- 这是否将在多年的过程中使用并扩展
- 应用程序的扩展是未知的，因此是无限的
真的归结为懒惰。您想花多少时间从 UI 重新设计系统？因为没有业务层意味着您的 UI 中的规则可能会在许多页面上重复。
如果这是一个概念证明或简短的演示或课程项目，那么再说一次。采取简单的方法。
于 2008-08-07T02:46:16.090 回答
1
可以接受吗？取决于你问谁和你的要求是什么。这个应用程序是您和其他一些人使用的一次性内部应用程序吗？也许这已经足够好了。如果它的目的是成为一个生产就绪的企业应用程序，并且会随着时间的推移不断增长和维护，那么您可能希望在前期投入更多的精力来构建一个可维护的应用程序。
关注点分离是构建可维护应用程序的关键设计技术。通过将表示、业务和数据访问逻辑混合在一起，您最终可能会得到一个非常脆弱且难以更改的应用程序架构。
于 2008-08-07T02:49:53.850 回答
1
这取决于。如果您的业务逻辑在您的点击事件和页面加载中，这是不可接受的。
您的业务逻辑似乎在 DAL 中的某个地方（例如，存储过程等），只要您保持一致，就可以了。只要您非常非常确定您的客户端将始终使用 SQL Server，那么这种方法就不是问题。
我认识一个同事，他的所有业务逻辑都在存储过程中，他的观点主要是瘦客户端到数据库后端：他销售的产品非常成功。但这只是因为他非常符合这一点。
于 2008-08-31T07:28:39.003 回答
0
如果应用程序是一个通用应用程序，那么业务逻辑层也可以用于完整的其他应用程序。就像，我通常在其他应用程序中使用与 CMS 相关的 BLL 类。
于 2009-10-23T07:59:29.147 回答