6

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.

NVM
  • 5,442
  • 4
  • 41
  • 61
  • @NVM: What specific type of resources are you concerned about for localisation? Language text, or layouts as well? – iCollect.it Ltd Oct 05 '10 at 12:19
  • @HiTech Magic. Primarily I am concerned about language text but the same would apply to images/icons etc. – NVM Oct 05 '10 at 14:24
  • 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... – NVM Oct 05 '10 at 14:40
  • 1
    @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. – iCollect.it Ltd Oct 05 '10 at 14:50
  • @HiTech Magic "Language text is always best managed and supplied via a central service" Why? – NVM Oct 05 '10 at 15:13
  • 1
    @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). – iCollect.it Ltd Oct 05 '10 at 15:22
  • Many thanks. What you say does make sense and wish I could give you the points! – NVM Oct 05 '10 at 15:37
  • @NVM: Just here to help and learn. The point system is nice, but the're not real :) – iCollect.it Ltd Oct 05 '10 at 17:38
  • 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. – NVM Oct 07 '10 at 12:12
  • @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. –  Jan 13 '11 at 02:32
  • 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. – NVM Jan 19 '11 at 07:41

2 Answers2

5

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.

PVitt
  • 11,500
  • 5
  • 51
  • 85
1

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.

Goblin
  • 7,970
  • 3
  • 36
  • 40
  • 1
    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. – PVitt Oct 05 '10 at 11:42
  • @Goblin as PVitt says, you have the same setup as mine. Your "common" assembly is my "Infrastructure" assembly. – NVM Oct 05 '10 at 14:26
  • No - my infrastructure is a module in itself. The 'common' assembly is separate from that. – Goblin Oct 05 '10 at 18:36
  • 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. – Goblin Oct 05 '10 at 18:44
  • 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 – NVM Oct 06 '10 at 17:12
  • 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. – Goblin Oct 06 '10 at 20:03
  • 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. – NVM Oct 07 '10 at 12:02
  • 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. – Goblin Oct 07 '10 at 12:33