2

We are working on LoB app with lot's of content. XAP download will be rather large I think for one time download. I'm planning to break solution into separate projects.

Not sure why - but I DO NOT like many many projects in solution. IMO it is not very good idea. Even when we were working as a large team - it was pain with many projects.

Even now when I'm using MEF/PRISM - there still going to be some core dependencies like:

  1. PRISM libraries
  2. Interfaces
  3. Navigation
  4. Shell/Bootstrapper
  5. App styles
  6. Converters/Commands/Validators
  7. etc.

And than I'm going to have modules that will use all that CORE stuff. Modules will have following inside them:

  1. RIA Services client side
  2. ViewModel's
  3. Views

Those modules will be loaded on demand using MEF. I think size-wise all those modules will be larger than core module because of ammount of logic in them.

I expect to have about 5-6 modules and CORE. I think that will give me reasonable number of client-side projects and libraries/XAPS and it will be manageable solution to work with.

Do you see any issue with breakdown like this? Some online videos will make 7+ projects out of CORE module. What's a point? I think it adds to complexity. Than they show 3-4 DLL out of module. One for views, one for viewmodels and so on. They still need to be loaded together so why?

I'm looking for do's and dont's from you guys who went through this..

Thank you!

1 Answer 1

Reset to default
2

Why do you feel that a solution with multiple projects is a BAD IDEA?

If your only doubt about this approach is that the solution will become cluttered then you can simply create multiple solutions, each with a different development perspective.

Solution == Perspective Approach

A solution is merely a collection of projects and defines building a series of projects. In my project setups I will typically have a Server side Solution, Business Entity Solution, a number of different Presentation Layer solutions and a Master solution that builds all projects.

Projects in the Server Side Solution may be in the Business Entity Solution as well. This way developers only need to develop in the solution/perspective which is applicable to them. This avoids the clutter of large numbers of projects.

3
  • Good points. But WHY I need to do that if those small projects will refer to each other anyway? We had such solution once and ended up consolidating it into bigger project. Versioning and deployment really problematic with so many libraries to keep track of.
    – katit
    Commented Aug 15, 2011 at 19:03
  • Yes unfortunately this is the problem with the Silverlight/PRISM architecture. I found this pain can be minimized with a componentized architecture in which libararies are all versioned together and branched together under that version in TFS. For deployment I would build the Master solution which built all projects in that release branch and then I had a custom deployment script that would take build artifacts and deploy them to their appropriate environments. This is how we worked around this and the only pain was maintaining our own deployment scripts.
    – maple_shaft ♦
    Commented Aug 15, 2011 at 19:23
  • Sure it can be handled. But main question remain :) Why do I need to deal with all this issues just so I have 100 projects? I guess I'm looking for "pains" I will experience if I don't go this way and stay with core+interfaces+modules structure? VS also seems to be slower when you have multiple projects
    – katit
    Commented Aug 15, 2011 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.