Should a BLL be stateless?

Question

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.

Answer 1

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.