We have a central management of permissions used across the solutions in one of the solutions. We use Redis to store the permissions and this part works fine.
The issue is that in order to display the localized names of permissions, we need to include DomainSharedModule of each solution into the management solution which does not seem right and creates coupling:
[DependsOn(typeof(OtherSolution1DomainSharedModule), typeof(...) ...)]
public class ManagementDomainSharedModule : AbpModule { ... }
- i.e. the resources from Solution1 are visible, but from Solution2, ... SolutionN - not.
How to avoid coupling, but still be able to display the localized names of all the permissions from the cache?
3 Answer(s)
-
0
Hi,
It seems we faced the same problem while developing micro-service template and found a different solution.
By a service
We created a centralized localization system with a separate simple Http API manages all the localizaiton. If you create a new microservice solution you'll see this Dynamic Localization option: <img src="/QA/files/3a19d642dc4ba66c8ec4e99eda7f78d3.png" alt="ABP Microservice dynamic localization" width="360" />
This options adds a new project to your solution to provide localizations to other services and more. In this system it supports changing them at runtime dynamically by using Language Management module, but in your case you can aggresively cache them if you do not want to change them at runtime and one-time you can get localizations.
If you interested this approach, I recommend you to create a new microservice template with dynamic localization option and check how it's implemented.
By a common data source (database table, file on cdn etc.)
Or, instead of creating a standalone service for it, each service can seed their own localizations into a shared database and all of your services can use this database or a file on CDN and the table to use localization. But in that case, you'll still need to use reference for Domain.Shared layers to access Solution1Resource, Solution2Resource etc. classes. Still, you can build a custom system to localize with a string resource name instead strong-typed C# class.
-
0
Maintaining yet another solution does not seem like a great idea to me. Nor is it great to add coupling from numerous solutions by adding a Domain.Shared reference to the management solution for the sake of localizing a page.
But as I understand, there is no other option. Well, actually one more - a trade-off option - could be to make API request to abp/application-localization of each solution (supposing that all of them will be running in the production system) and to create a client-side dictionary (dictionaries), then - to extract the display name by the given localization key...
-
0
Maintaining yet another solution does not seem like a great idea to me. Nor is it great to add coupling from numerous solutions by adding a Domain.Shared reference to the management solution for the sake of localizing a page.
But as I understand, there is no other option. Well, actually one more - a trade-off option - could be to make API request to abp/application-localization of each solution (supposing that all of them will be running in the production system) and to create a client-side dictionary (dictionaries), then - to extract the display name by the given localization key...
Instead of maintaining another project, you can use a shared access data source, like a shared CDN folder for json localization files or a shared redis cache that all applications can access directly etc. It depends how much flkexibility you need
