为了重新路由到 DAL 而在 BLL 对象中编写一堆 2 线性函数是否值得？
对我来说这似乎很愚蠢。 我没有得到什么？
It seems pretty silly to me. What don't I get?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
对我来说这似乎很愚蠢。 我没有得到什么？
It seems pretty silly to me. What don't I get?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（4）
我遇到过这样的情况，我的应用程序调用业务层来选择值列表。 然后业务层调用Dal来进行数据访问。 在很多情况下，业务层方法没有明显的理由进行传递，但它确实为将来添加业务逻辑、数据处理等留下了空间。 它还有助于使您的应用程序解耦，这将使测试变得更加容易。
所以，我说保留一行，但如果您的插入、更新等仍然是一两行，您需要重新考虑在哪里进行验证和业务级数据处理。
I've run into cases like this where my app calls a business layer to select a list of values. The business layer then calls through to the Dal to do the data access. In a lot fo these cases, there is no apparent reason for the business layer method that does the pass through, but it does leave room to add business logic, processing of the data, etc in the future. It also helps keep your app decoupled, which will make testing much easier.
So, I say keep the one liners, but if your inserts, updates, etc are still one or two lines, you need to re-think where you are doing your validation and business level data processing.
如果您的 BLL 从不进行验证或实现任何业务逻辑并且始终保持 2 个衬垫，那么是的，这是非常愚蠢的。 但如果您这样做，您可能错过了拥有业务逻辑层的要点，并且您可能一直在 UI 中进行验证，或者在 UI 或 DAL 中添加业务逻辑。 很少有应用程序不需要验证并且没有业务逻辑。
If your BLL never does validation or implements any business logic and always remains 2 liners, then yes it is pretty silly. If you do this though, you've probably missed the point of having a business logic layer and you have probably been doing your validation in the UI, or adding business logic in your UI or your DAL. There are very few applications that require no validation and have no business logic.
虽然 Rob 和 Bullines 经常正确地认为这样做的需要指向了更深层次的问题，但在某些合理的情况下，直接进入数据访问层是非常有意义的。 编写一个无脑的方法（或者更糟糕的是，整个对象模型）来包装数据访问层是任何程序员所做的最无用的事情之一，所以不要这样做。 如果有正当理由，您可以放心不通过业务逻辑层。
While Rob and Bullines are often correct that the need to do this points to a deeper problem, there are legitimate instances in which going straight to the data access layer makes perfect sense. Writing a brainless method (or worse, entire object model) to wrap the data access layer is among the least useful things any programmer can ever do, so don't. You can feel good about not going through the business logic layer if there's a legitimate reason.
业务逻辑应该在您的 BLL 中。 如果您最终在 BLL 中得到“2 行函数”，您是否不小心将该业务逻辑放入了 DAL 或 UI 中？
Business logic should be in your BLL. If you end up with "2 liner functions" in your BLL, did you accidentally put that business logic in your DAL or UI?