The biggest problem of BLoC is the name “BLoC”
I really like BLoC.
As a state management plugin, BLoC has some definite advantages over the provider series, not even comparing it to the troublesome getX.
As a pattern, BLoC is also good because it allows you to write stable and robust code.
However, the name BLoC is confusing to some flutter developers.
Business Logic Component. A component that contains business logic?
I think we should start with a general definition of Business Logic.
What is Business Logic as we usually think of it?
https://en.wikipedia.org/wiki/Business_logic
Here is the definition from Wikipedia.
In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.
The area of the program that creates, stores, and changes data. This is a common definition.
Business Logic. This is distinct from the low-level details of dealing with databases, presenting the UI, system infrastructure, or generally connecting various parts of the program.
In the simplified Clean Architecture approach, which is divided into three layers, Presentation — Domain — Data, Business Logic usually belongs to the Domain layer.
Business Rules, which we talk about in the original 4 layers, are in the Use Cases layer and Entities layer. The only difference is whether they are enterprise wide or application specific.
Entities
Entities encapsulate Enterprise wide business rules.
Use Cases
The software in this layer contains application specific business rules.
Of course, layer definitions can be subjective. There are no fixed laws or rules, so depending on how you look at it, you might think that other layers can also contain Business Logic. Yes Yes, that’s all very fine and good,
but the Domain layer definitely contains Business Logic.
So what is the Business Logic (BL) that BLoC is claiming?
As you can see from paragraph below,
The business logic layer’s responsibility is to respond to input from the presentation layer with new states. This layer can depend on one or more repositories to retrieve data needed to build up the application state.
Think of the business logic layer as the bridge between the user interface (presentation layer) and the data layer. The business logic layer is notified of events/actions from the presentation layer and then communicates with repository in order to build a new state for the presentation layer to consume.
The definition of BL in the BLoC is not a common one.
In the first paragraph, the BLoC is only responsible for taking input from the presentation layer and reacting to it. It pulls data from repositories to construct the App State.
In the second paragraph, we’re suddenly asked to think of the Business Logic layer as a bridge between the Presentation and Data layers. Presentation layer and Data Layer? What the Data Layer?
Does the BLoC class then coincide with the Domain layer? Why does it say something different from the first paragraph? Why does it confuse us like this?
Let’s look again at the Wikipedia definition we saw earlier.
It is contrasted with the rest of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.
This is completely in conflict with Wikipedia’s definition, which excludes BL from generally connecting different parts of a program.
If you look at the picture at the bottom of that paragraph, BLoC is in the Application Layer(?) after all.
In the Presentation — Domain — Data structure we saw earlier, we have a BLoC layer between the Presentation and Domain layers.
But in the end, it belongs to the Presentation layer when we think of it as a typical three-tier structure. There’s nothing wrong with thinking of the Application layer as Presentation. As you can see in the top part of the figure, which is also divided into App-Domain-Data, BLoC belongs to a different layer than Domain in the three-tier structure.
BLoC doesn’t belong in the Domain layer.
So why did I write Business Logic in the BLoC part of the above figure?
It’s because that part is BL, according to the definition of BL in BLoC. Weird, right?
Here are the conclusions we’ve come to so far.
The Domain layer contains the Business Logic.
The Business Logic Component (BLoC) does not belong to the Domain layer.
We have this contradiction.
It would be natural to think that one of them is wrong, and that it’s not in the general definition, but in the definition of BL in BLoC.
So why do we have this particular definition?
I think it’s just because of the name. The creator of the BLoC plugin Felix Angelov is not guilty, it’s just the person who named the pattern BLoC that’s the problem. The word business logic shouldn’t have been in there.
Anyway, Business Logic in BLoC is not what developers usually think of.
So let’s not put all of our normal, common business logic in our BLoC.
