Hi all,
I have a question pertaining to the structure of the solution file for a large (200+ tables) Csla/Silverlight application. I know the normal format is as follows:
Solution file - BelAir
Silverlight project - BelAir
Web project - BelAir.Web
Silverlight Class Library project - BelAir.Business.Client
Windows Class Library project- BelAir.Business.Server
Wcf project - BelAirWcfHostWeb
Or would it be better to break up the projects so there won't be so many classes in each project file as follows:
Solution file - BelAir
Silverlight project - BelAir
Web project - BelAir.Web
Silverlight Class Library project - BelAir.Business.Operations.Client
Silverlight Class Library project - BelAir.Business.Customer.Client
.
.
Windows Class Library project - BelAir.Business.Operations.Server
Windows Class Library project - BelAir.Business.Customer.Server
Wcf project - BelAirWcfHostWeb
and if I do the above method, should I have them all under the namespace BelAir.Business or should I have different namespaces as BelAir.Business.Operations, BelAir.Business.Customers, etc.
I realize each one would work but I am trying to figure out now which will be the best to start with and build the project. I don't want to get a month into the project and say "I wish I would have done it this way, but it would take too much time to convert it now." So, any advice would be most appreciated and your experience in large projects in Csla and Silverlight.
CyclingFoodmanPA
As with anything, you should use features because you need them. That includes the feature of creating multiple assemblies/projects.
The drawback to having multiple assemblies is that they often need to reference each other, and circular references aren't allowed. So as soon as you have a cross-dependency between two assemblies you are forced to have a third, where you can put the common dependency to break the circular reference.
Repeat that a few times in a large project, and you can easily have a lot of little assemblies that exist only to avoid circular references, not because of any logical organization of code.
But of course multiple assemblies can provide some value.
A primary benefit is if you are working in a large or distributed team, because you can (to some degree) avoid developers stepping on each other by having sub-teams work on specific assemblies. I've found this to be limited in value in real life, but it sounds great in theory.
If you CAN avoid cross-dependencies, you can modularize your application. This is powerful when combined with the .NET 4.0 MEF technology, but is crippled due to ClickOnce insisting on installing all referenced assemblies rather than downloading code on-demand. But Prism has an on-demand scheme for Silverlight, so that's a plus.
Anyway, the point is that you can, potentially, only deploy the parts of the app the user needs/wants, thus reducing the app footprint. But unless you are embedding big graphic/audio resources in your assemblies, most .NET assemblies aren't big enough where this is a major concern, and the complexity of downloading parts of the app on demand offsets the small gain in downloading fewer DLLs.
I'm sure there are other pros and cons - my point is to think about these pros and cons and decide if the benefits of having many assemblies outweighs the costs.
CSLA .NET 1.x had several assemblies. People hated that. It was one of the major pain points with CSLA at the time. CSLA .NET 2.0 and higher is one assembly, which makes 99% of the people happy. There's the 1% that builds a WPF app and doesn't want the web or WinForms code - but realistically we're talking a few k bytes, so it is hard to justify the complexity of having 5-7 assemblies for CSLA .NET to avoid downloading so few bytes...
Copyright (c) Marimer LLC