Silverlight Application Project Structure - How much is too much?

Question

My team is working on creating our first Silverlight 4 Application. First of all to give a bit of detail on the actual project. It will be Silverlight 4 that is designed to run Out-oF-Browser and we will be using WFC for data services with our own implementation of Dataobjects. (NO entity framework, LINQ-to-SQL, etc). We have a few consultants in that are recommending a solution structure that contains more than 11 individual projects. To us there just doesn't seem to be a reason for it, can anyone see any justification as to why something like the following might be needed?

• Project.Client - Assets, Styles, Views
• Project.Common - Converters, Helpers
• Project.Data - Unknown purpose (Client project)
• Project.Infrastructure - Commands, Constants, Interfaces, Logging
• Project.MajorFunctionA - "Business Logic for major function A of the application"
• Project.MajorFunctionB - "Business Logic for major function A of the application"
• Project.MajorFunctionC - "Business Logic for major function A of the application"
• Project.Models - Abstracted access to WCF Services
• Project.UIControls - Custom controls for the UI
• Project.UnitTests - "Potentially all unit tests"
• Project.ViewModels - View models for the UI
• Project.Web - Host project for the silverlight app - no code
• Project.Web.Infrastructure - Data Objects and WCF Services

Now, our major confusion comes with why we wouldn't just namespace things out to keep them separate, as well as things like "Project.MajorFunctionA" which is just a small component of the application, why should it have its own project. (Keep in mind that the Views and ViewModels for that specific function would NOT live in that project but the other Client/ViewModel projects.

We are just looking for some validation, as I don't see any reason for this.

Answer 1

Agreed: Use namespaces for logical organization, not projects. One approach is to think of projects as units of deployment. Will Project.Client always be deployed with Project.ViewModels? Project.Models? Is one referencing the other? Just include in the same project and use namespaces for organization.

A few reasons why you may want to separate Silverlight class libraries/applications into individual projects:

• Reuse. You want to develop APIs that will be used for other applications. Your Project.Infrastructure may fall into this category.
• Modularity. MajorFunctionA is only used by the end user 20% of the time. Maybe only certain authenticated users have access. Maybe it is only access when navigated to a specific page that noone goes to. You could choose to build into separate Silverlight apps and only download the .xaps as needed using frameworks like MEF or PRISM.
• Developer Workflows. One team in one city/office is working on Project.Client and another team in another city/office is working on Project.Models. It might make sense to build into separate projects to make life easier.

One other thing to note about assemblies is that you can't have circular references between assemblies. In other words, if ClassA and ClassB are in the same assembly, ClassA can reference ClassB, and ClassB can reference ClassA. But if they're in separate assemblies, they can't. Now, if your classes have a lot of circular references, that's probably not a good thing, but sometimes it's difficult to avoid, and your options are much more limited if they happen to be in separate assemblies. But on the flip side, increasing the number of assemblies limits the opportunity for circular references, which can improve the quality of your design. Just something else to be aware of.

Following that logic, one alternative would be grouping Project.Client, Project.Data, Project.Model, Project.UIControls, and Project.ViewModels in one project and grouping Project.Common and Project.Infrastructure into another. MajorFunctions could be left separate or grouped into Project.Client. You would end up with:

• Project.Client - Application specific interface, view models, and models.
• Project.Infrastructure - Common, reusable helpers, converters, and interfaces.
• Project.UnitTests
• Project.Web
• Project.Web.Infrastructure

Also. There's not really a correct answer for this. I'm tagging as Community Wiki.