Home/ Questions/Q 159147
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T10:48:26+00:00

I’m currently tasked with teaching all the developers, in the company I work in,

  • 0

I’m currently tasked with teaching all the developers, in the company I work in, about Silverlight (v2). The only problem is that I don’t have any real Silverlight experience myself. Of course I’ve studied all the technical details about stuff like databinding, layout etc. so I can help my colleagues. But one thing that is hard to find any information about is the general project structure.

I’ve decided to follow the P&P Prism 2 path (and maybe even throw some WPF in the mix later on) and so I was wondering if any of you clever people have experience in developing a real project using Prism 2 or even just WPF, and if you had any suggestions about the project/solution structure? Such as ‘Where do you put views?’ or ‘Do you have any module project naming conventions?’ etc.

Any help will be greatly appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. This is purely based on my experience using Prism for WPF, not Silverlight. I’m not an expert at Prism and could easily change my mind on some of these. 🙂

    • It’s tempting to make a module for everything. Don’t. Your build time will quickly blow out and you’re left dealing with a very fractured solution. Instead I have one Main Module, which is loaded statically, and contains everything I want in the base package. Any addons or extras become other modules that are loaded dynamically. It might be worth breaking that one module down a bit, but keep the number small. This also helps with load time.

    • Not sure if this ones a good idea, but I like to keep the View and ViewModel interfaces in the same file as the View/ViewModel themselves. I like this because the MVVM pattern can produce alot of files, and this keeps the file count down. The down-side is that the Inteface and it’s implementation are harder to separate, but I’m unlikely to need to do this, and this technique doesn’t interfere with testing, which is the other benefit.

    • Views tend to go into a Views folder, then a folder for each View. The folder for each View includes the View, the ViewModel, and the Presenter if one is needed.

    • From the reference implementation, make an Infrastructure project for all common classes that need to be shared between modules. The reference implementation has more details but this can be used for all sorts of things like common service interfaces, constants, etc.

    • 0