没有业务逻辑层的ASP.Net 2.0应用程序?

拥有一个没有BLL(业务逻辑层)的 ASP.Net 2.0 应用程序是否“可接受”如下?

  1. SQL Server Data Storage & Stored Procedures
  2. Data Link Layer (Strongly Typed Table Adapters) connecting to Stored Procs
  3. Presentation Layer ASPX Pages with Code behind and ObjectDataSource for connection straight to the DLL

即使业务逻辑完全可以在演示文稿的代码中验证,BLL总是更可取的吗?不使用BLL有什么潜在的缺点?

0

5 答案

像其他一切一样,它是环境的,取决于系统的使用。你需要问自己的问题是:

  1. 这是否会被积极开发
  2. 这是否会在多年的过程中使用并扩展
  3. 应用程序的扩展是未知的,因此是无限的

真的,这归结于懒惰。您希望花费多少时间从UI重新使用系统?因为没有业务层就意味着您的用户界面中可能存在许多页面的重复规则。

如果这是一个概念证明或短期演示或类项目,那么再一次。采取简单的方法。

0
额外

这取决于。如果您的业务逻辑处于您的点击事件和页面加载中,则无法接受。

看起来你的业务逻辑是在DAL中的某个地方(例如,存储过程等),只要你一致,就没问题。只要你非常确信你的客户端总是使用SQL Server,那么这种方法就不成问题了。

我认识一个在存储过程中拥有所有业务逻辑的同事,他的观点大多是数据库后端的瘦客户端:他在销售产品方面一直非常成功。但那只是因为他非常符合它。

0
额外

只要你了解后果,这是可以接受的。 BLL的主要原因是在整个应用程序的其他地方重新使用该逻辑。

如果您在表示代码中拥有所有验证逻辑,那么实际上很难在应用程序中的其他位置重用。

0
额外

如果应用程序是通用应用程序,那么业务逻辑层也可以用于其他完整的应用程序。就像我通常在其他应用程序中使用我的CMS相关的BLL类。

0
额外

是否可以接受?取决于你问及你的要求是什么。这个应用程序是您和其他一些人使用的内部一次性应用程序吗?也许这够好。如果它的目的是要成为一个可以随时发展和维护的生产预备型企业应用程序,那么您可能需要预先投入更多的努力来构建可维护的应用程序。

分离问题是构建可维护应用程序的关键设计技术。通过将演示文稿,业务和数据访问逻辑混合在一起,您最终可能会遇到一个非常脆弱的难以改变的应用程序体系结构。

0
额外