Best Practice WPF Prism Resources

Question

I have a a WPF prism desktop app with a few modules. In the past I've put all my localized resources in common resource files in the infrastructure assembly and referenced it in all modules.

But lately I have been wondering if that is indeed the right approach from a maintainence perspective. In essence it also sort of breaks modularity. Would having module specific resource files in the the modules themselves be a better approach in the long run?

All thoughts appreciated.

Uterus

@NVM: What specific type of resources are you concerned about for localisation? Language text, or layouts as well? – Winfredwinfrey

@HiTech Magic. Primarily I am concerned about language text but the same would apply to images/icons etc. – Uterus

I don't understand what you mean by layouts. I don't give any fixed sizes for any controls ie they are always on Auto and WPF takes care of layouts and also left to right/right to left layouts etc... – Uterus

@NVM: Language text is always best managed and supplied via a central service, usually driven by backend database/datafiles rather than resource strings. Most published text binding solutions for Silverlight are overly bulky for their purpose. We now bind using keys in attached properties. Other assets however do need a traditional MS "named resource file" approach and per module is definitely preferred. – Winfredwinfrey

@HiTech Magic "Language text is always best managed and supplied via a central service" Why? – Uterus

@NVM: The set of strings may be authored across multiple files, but localisation is performed as a complete set for each language. Delivery, back to the app, is easier if you treat each language (all strings across the entire app) as a single unit of plug-in data. This is purely based on practical experience of localising dozens of business apps (and computer games). – Winfredwinfrey

Many thanks. What you say does make sense and wish I could give you the points! – Uterus

@NVM: Just here to help and learn. The point system is nice, but the're not real :) – Winfredwinfrey

I think points are important on a QA website like this. Although there always are exceptions, when someone with say 100k points gives an answer its just safe to assume that he really knows what he is saying. Obviously points usually aren't the real motivation behind people helping others out here. – Uterus

@NVM, did you find a solution for this localisation problem. I totally agree with you on this matter of modularity and trying to achieve the same but with no success yet. – Yawp

Well yes. I now have resources in individual assemblies. Everything remains the same but now each assembly uses its own resources. It was not exactly a problem to start with. I just wanted to know whats the right approach. Implementation wise at the top level things remain the same either way. – Uterus

Answer 1

As far as one of Prism's main targets is modularity it just seems obvious to put your resources only in the appropriate assembly. Sharing resources via one centralized assembly is the opposite of modularity. Doing it the centralized way will get you another type of DLL hell at the time you want to add more (optional) modules. You will have to update the common assembly without the knowledge of the modules that use the assembly. And determining which module is present just again violates the modularity itself. The other way is to always update the common assembly to the latest version. Whatever you do, following the centralized approach forces you to build all your modules backward-compatible.

This is my point of view at the moment. But as far as I'm working with Prism for only a few weeks now I'm not quite sure if my statement is the way how it should be done.

Overly

Thanks PVitt. That does answer my question!! Cheers – Uterus

Answer 2

I never have references between the individual modules when using Prism (unless one module is indeed an enhancement of another). I tend to put shared resources, interfaces etc. in a 'common'-assembly that is referenced by all modules and the assembly containing the shell. Things that implement an interface is then retrieved via the IoC-container and the implementation is placed in the module where it 'belongs'.

As you write - having them in the infrastructure module breaks one of the ideas behind Prism.

Giltedged

Well, you also have them in the infrastructure module just that you name it not that way. What else is your assembly that holds your resources than an infrastructure assembly. – Overly

@Giltedged as PVitt says, you have the same setup as mine. Your "common" assembly is my "Infrastructure" assembly. – Uterus

No - my infrastructure is a module in itself. The 'common' assembly is separate from that. – Giltedged

Just to clarify - to me infrastructure is about where/how do I get/send data to and from the application. Resoources such as localizable strings, icons, styles in resource dictionaries is not part of the infrastructure. – Giltedged

Well then each of your module has a dependency on two other dll's in your project (lets drop the technical terms) instead of the one that I have. I think in essence it breaks modularity even further then it does in my case – Uterus

Yes - you are right - my modules (whatever they contain) depend on an assembly with the Business rules and one with common functionality (base-classes, interfaces, resources etc.) You may have better encapsulation - I may have more opportunities to uphold Do not Repeat Yourself (DRY) - it's a matter of trade-offs. – Giltedged

Just for the sake of discussion, if I understand it right, the way you have things setup you are only trying to achieve UI modularity and not generic modularity. If you have all your business rules in one module you've coupled everything together even though you have multiple projects giving the appearance of modularity. – Uterus

Correct. I need to solve: "Customer A can see module 1 and 2", "Customer B can see module 2, but not 1" scenarios. The domain is cohesive and shared between the modules. – Giltedged