WPF Prism Resources for Best Practice

I have a WPF prism application with several modules. Previously, I placed all my localized resources in shared resource files in the infrastructure assembly and referred to it in all modules.

But lately, I have become wondering if this is really the right approach in terms of maintenance. In essence, it is also a kind of modularity gap. Does the module have specific resource files in the modules themselves the best approach in the long run?

All thoughts are appreciated.

+6
resources wpf prism cal
source share
2 answers

Since one of the main goals of Prism is modularity, it just seems that your resources can only be used in the corresponding assembly. Sharing resources through one centralized assembly is the opposite of modularity. Performing this centralized method will give you another type of DLL add-on at a time when you want to add additional (optional) modules. You will need to update the general assembly without knowing the modules that use the assembly. And determining which module is present simply violates modularity itself. Another way is to always upgrade the general assembly to the latest version. No matter what you do, after a centralized approach, you will create all your modules backwards compatible.

This is my point at the moment. But since I have been working with Prism for only a few weeks, I'm not quite sure that my expression is the way this should be done.

+5
source share

I never have links between separate modules when using Prism (unless one module is really an improvement on another). I tend to post shared resources, interfaces, etc. In the "general" assembly referenced by all modules and the assembly containing the shell. Things that implement the interface are then retrieved through the IoC container, and the implementation is placed in the module where it belongs.

As you write, the presence of an infrastructure module breaks one of the ideas underlying Prism.

+1
source share

All Articles