question: Is it a good practice to use "business" bloc
chedwin41 opened this issue · comments
I'm engaged in developing several large applications that all connect to a single backend system. To put it simply, these applications interact with backend data entities—such as clients, products, and inventory—through basic create, read, update, and delete (CRUD) operations.
Each user interface typically requires data from multiple business entities to function effectively. Initially, we adopted the bloc pattern in the following manner:
This is a simplification but at the end,we found ourselves repeatedly performing the same actions across different pages to, say, fetch product details.
Consequently, we explored an alternative method as illustrated below:
In this approach, we centralized the common bloc properties that were previously duplicated across each page.
For instance, a product bloc might contain a property for a single product item and an event to initiate its loading. However, the interaction with the ui still occurs uniquely within each page's specific bloc.
Is this method considered a best practice? Are there any other recommended approaches?
Hey!
No this is not considered a best practice. In general you want to have one Bloc/Cubit for each feature (which usually means one Bloc per page).
For your situation, if you haven't included DataProviders already they might help you. You might be able to move most of the Repository logic to the DataProviders and then use the Repository as the middle layer. This is actually consistent with the Bloc architecture: https://bloclibrary.dev/architecture/
If you already have DataProviders defined, you might be able to use helper classes that will contain the code that is shared by more than one Blocs
Hello, thank you for your response.
I'd like to provide some additional details about our situation and our objectives. We have common widgets that are shared across different views and even applications. From my understanding, the preferable approach should resemble the following:
(In these diagrams, the orange components are the ones being reused).
What we have experimented with is depicted below:
In this model, blocs are still organized by feature but are utilized in multiple subwidgets that require these blocs to function correctly. This strategy facilitates the sharing of widgets between views without the need to propagate properties through numerous subcomponents.
Additionally, each component manages its own loading state based on the bloc it relies on. For instance, some components in my view that utilize the product bloc can display product details, etc., while the stock indicator might not load. This loading behavior is managed within each individual featured component.
This approach feels akin to assigning one bloc per feature, yet each feature is utilized by multiple components.
Hey, these diagrams are very different from the initial one, because there aren't two layers of Blocs and no Bloc depends on another Bloc. (That's good!)
In the two versions that you sent the main change seems to be that the ViewClientBloc is split in two Blocs. I believe that whether this is a good idea or not depends on what that Bloc does, and is not specific to the BLoC architecture.
The Single-Responsibility Principle comes to mind: "A module should be responsible to one, and only one, actor." If that Bloc is responsible to more than one actors (user group/stakeholder group) or if there is more than one reason to change, perhaps breaking it into two is a good idea.
Which widget will depend on the Bloc isn't that important. I think it's actually better to have a BlocBuilder (or similar widget) lower in the widget tree to avoid unnecessary rebuilds. (And the widget that includes the BlocProvider will depend on the Bloc anyways.)
Creating a different module for the grouped classes has to do with your enterprise architecture. Do keep in mind that, if your grouped classes (cmp, bloc, repository) are in one module and the BlocProvider is separate from it; the module will need to expose the Bloc which in that case will be an implementation detail. I believe that a widget which includes a BlocBuilder and the widget UI can be adequately reused. That being said, do keep in mind that you know your enterprise's code much better than me.