Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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!

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

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.

share|improve this answer
    
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 Aug 15 '11 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 Aug 15 '11 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 Aug 15 '11 at 19:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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