Hi,
We have a modular architecture with three separate modules: PPM, MEX, and OEX.
PPM consumes both MEX and OEX internally. In our final monolithic solution, we consume all three modules together. Some of MEX's endpoints and permissions are exposed through PPM. Now, we want to make PPM behave differently depending on whether MEX or OEX is enabled. To achieve this, we are considering using Global Features inside PPM to conditionally enable or disable parts of the module (e.g., permissions, endpoints, services) related to MEX and OEX.
Is this a recommended and clean approach in ABP Framework? Or would you suggest a different pattern for managing such conditional module behavior without tightly coupling the modules?
Thanks in advance!
Check the docs before asking a question: https://abp.io/docs/latest Check the samples to see the basic tasks: https://abp.io/docs/latest/samples The exact solution to your question may have been answered before, and please first use the search on the homepage.
Provide us with the following info:
🧐 Hint: If you are using the ABP Studio, you can see all the information about your solution from the configuration window, which opens when you right-click on the solution and click on the Solution Configuration button.
- Exception message and full stack trace:
- Steps to reproduce the issue:
2 Answer(s)
-
0
- Using Global Features in ABP Framework is a recommended and clean approach for enabling or disabling parts of a module (such as permissions, endpoints, or services) based on the presence or activation of other modules. This pattern is specifically designed to allow modules to adapt their behavior without introducing tight coupling between them.
- By leveraging Global Features, you can conditionally register or expose functionality in your PPM module depending on whether MEX or OEX is enabled, as shown in your code example. This keeps your modules loosely coupled and maintains modularity, since the feature flags are managed centrally and do not require direct references between modules.
- This approach is documented and encouraged in the official ABP documentation for modularity and global features. It is preferable to alternatives such as hard dependencies or runtime type checks, which can lead to maintenance and upgrade issues.
If you need to further customize or override module behavior, you can also use the extensibility and customization mechanisms provided by ABP, such as service replacement or module extension points.
Sources:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
-
0
hi
Some of MEX's endpoints and permissions are exposed through PPM.
Can you explain more details about this?
Now, we want to make PPM behave differently depending on whether MEX or OEX is enabled.
It's best for the modules to be completely independent from each other.
Why do your three modules need to reference each other?
Thanks.
