没有业务逻辑层的 ASP.Net 2.0 应用程序？
没有 BLL（业务逻辑层）的 ASP.Net 2.0 应用程序是否“可接受”，如下所示？
- SQL Server 数据存储和 存储过程
- 数据链路层（强类型表适配器）连接到存储过程
- 表示层 ASPX 页，带有代码隐藏和用于直接连接到 DLL 的 ObjectDataSource
即使业务逻辑在表示的代码隐藏中完全可验证，BLL 总是更可取吗？ 不使用 BLL 有哪些潜在缺点？
Is it "acceptable" to have an ASP.Net 2.0 application without the BLL (Business Logic Layer) as the following?
- SQL Server Data Storage & Stored Procedures
- Data Link Layer (Strongly Typed Table Adapters) connecting to Stored Procs
- Presentation Layer ASPX Pages with Code behind and ObjectDataSource for connection straight to the DLL
Is a BLL always preferable, even if business logic is entirely validatable in the presentation's code behind? What are the potential drawbacks for not using a BLL?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
只要你明白后果就可以接受。 拥有 BLL 的主要原因是在整个应用程序的其他地方重用该逻辑。
如果演示代码中包含所有验证逻辑，那么在应用程序中的其他地方重用确实会变得困难。
It's acceptable as long as you understand the consequences. The main reason you'd have a BLL is to re-use that logic elsewhere throughout your application.
If you have all that validation logic in the presentation code, you're really making it difficult to re-use elsewhere within your application.
与其他一切一样，它也是环境因素，并且取决于系统的使用。 您需要问自己的问题是：
真的，这归结为懒惰。 您想花多少时间从 UI 重新设计系统？ 因为没有业务层意味着 UI 中的规则可能会在很多页面上重复。
如果这是概念证明或简短的演示或课堂项目，那么又是这样。 采取简单的出路。
Like everything else it is environmental and depends on the use of the system. The question you need to ask your self is:
Really it comes down to laziness. How much time to do you want to spend reworking the system from the UI? Because having no business layer means duplication of rules in your UI across possibility many many pages.
Then again if this is a proof of concept or short demo or class project. Take the easy way out.
可以接受吗？ 取决于你问谁以及你的要求是什么。 这个应用程序是您和其他一些人内部一次性使用的吗？ 也许这已经足够好了。 如果它的目的是成为一个生产就绪的企业应用程序，并将在未来几年内不断发展和维护，那么您可能需要预先投入更多的精力来构建可维护的应用程序。
关注点分离是构建可维护应用程序的关键设计技术。 通过将表示、业务和数据访问逻辑混合在一起，您最终可能会得到一个非常脆弱且难以更改的应用程序体系结构。
Acceptable? Depends who you ask and what your requirements are. Is this app an internal one-off used by you and a few other people? Maybe this is good enough. If it's meant to be a production ready enterprise application that will grow and be maintained over the years, then you probably want to invest more effort up-front to build a maintainable app.
Separation of Concerns is a key design technique for building maintainable apps. By mixing presentation, business, and data access logic all together, you can end up with a very fragile difficult to change application architecture.
这取决于。 如果您的业务逻辑位于您的点击事件和页面加载中，则这是不可接受的。
看来您的业务逻辑位于 DAL 中的某个位置（例如，存储过程等），只要您保持一致，就可以了。 只要您非常非常确定您的客户将始终使用 SQL Server，那么这种方法就不是问题。
我认识一位同事，他的所有业务逻辑都在存储过程中，他的观点主要是数据库后端的瘦客户端：他销售的产品取得了巨大的成功。 但这只是因为他对此非常一致。
It depends. If your business logic is in your click events and page loads, it is NOT acceptable.
It appears that your business logic is somewhere within the DAL (e.g., stored procedures and such), just as long as you are consistent, it's fine. As long as you are very, very sure that your clients will always be using SQL Server then this approach is not a problem.
I know a colleague who has all his business logic in stored procedures that his views are mostly thin clients to database backends: he has been immensely successful with the product that he sells. But that's only because he's very consistent with it.
如果应用程序是通用的，那么业务逻辑层也可以用于完整的其他应用程序。 就像，我通常在其他应用程序中使用与 CMS 相关的 BLL 类。
If the application is a general one, then the business logic layer can be used in complete other applications too. Like, I normally use my CMS related BLL classes in other applications.