BLL 应该是无国籍的吗?

发布于 2024-10-03 08:25:25 字数 254 浏览 1 评论 0原文

我正在考虑为我的应用程序构建 BLL。从我所看到/读到的来看,BLL 似乎应该是无状态的。这不是意味着所有 BLL 方法都可以是静态的吗?或者我至少只需要每个 BLL 类的一个实例?出于某种原因,这对我来说似乎很奇怪,所以我想在我深入研究我的实验之前,我最好检查一下我是否弄错了方向。

我还认为这意味着 BLL 对象不应该包含数据,因为数据代表状态 - 因此对于调用的每个 BLL 操作,需要重新查询(或从缓存中获取)然后丢弃所需的任何数据。听起来对吗?

谢谢。

I'm toying with building a BLL for my application. From what I've seen / read, it seems the BLL should be stateless. Doesn't this mean all BLL methods could be static? Or I'd at least only ever need one instance of each BLL class? Which seems odd to me for some reason, so I thought I better check I wasn't getting the wrong end of the stick before I delved too far into my experimentation.

I'm also thinking this means the BLL objects should never contain data, because the data represents state - so for each BLL operation invoked, any data that is needed needs to be requeried (or fetched from cache) and then discarded. Does that sound about right?

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

被翻牌 2024-10-10 08:25:25

理论上,是的,无状态 BLL 意味着所有方法都可以是静态的。

但是,有一些注意事项可能会让您倾向于使用 BLL 对象的实例而不是静态对象。

  1. 静态方法引入了类之间的紧密耦合,并阻止您使用例如接口来松散耦合依赖项。接口的使用提高了 BLL 的可测试性,因为现在可以在为服务层编写单元测试时对其进行模拟。如果您的 BLL 方法是静态的,那么如果没有“解决方法”,您通常无法做到这一点(例如,您在 .Net 环境中需要 TypeMockMicrosoft Fakes )。

  2. 在复杂的 BLL 方法(例如大型事务逻辑)上,您可能希望将每个业务规则重构为多个离散方法,并且在输出上,可能将所有验证和规则违规累积到一个包含以下内容的聚合结果中:所有违规行为。在这种情况下,分流要验证的一个或多个实体并累积规则违规可能会很麻烦,而是选择在类实例上对这些实体进行有状态存储。实例 BLL 的基类或泛型可以在此处提供帮助。

In theory, yes, a stateless BLL can mean that all methods can be static.

However, there are some considerations which may swing you toward using instances of BLL objects instead of static.

  1. Static methods introduce tight coupling between classes and prevent you from using e.g. interfaces to loosely couple dependencies. Use of interfaces improve the testability of the BLL since it can now be mocked when writing unit tests for the Service Layer. If your BLL methods are static, then you generally won't be able to do this without 'workarounds' (e.g. you would need TypeMock or Microsoft Fakes in a .Net environment).

  2. On a complex BLL method (e.g. large transaction logic), you may want to refactor each of your business rules into several discrete methods, and on the output, possibly accumulate all of the validation and rule violations into a single aggregated result containing all of the violations. In this case, it can be cumbersome shunting the entity / entities to be validated and accumulating the rule violations, and instead elect for stateful storage of these on a class instance. A base class or generic for your instance BLL can assist here.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文