Organizing code in separate Projects vs separate Namespaces

Question

I work in a .net c# application which contains 2 solutions for client and server. In server side there are 80+ projects that have been used to separate following Architectural layers,

• Infrastructure Layer
• Integration Layer (External Systems)
• Domain Layer
• Repository Layer
• Manager Layer
• Service Layer

In addition, almost every layer has test project.Now, the build time of the solution takes 2 to 3 minutes, and many developers (including me :)) feel we need to tackle this problem.

Therefore,proposed solution was to reduce the number of projects by merging the projects.In my view, it is probably a good solution to minimize the build time and we could achieve what we want.

Proposed solution is that we merge our projects into 3 areas, such as one library for production code, one library for test code, and one for deployment projects (WCF host ,etc) and logically divided layers in same project by separating the namespaces.

However, my concerns are

1. Could these separation good for the maintainability ? providing that more that hundread of classes for each namespace appox.
2. If we have common functionality such as helpers, where are we put those ?

Is there any other way to layering the solution ?

Answer 1

I guess you should split your solutions in logical layers.

As part of where do you put the helpers. Make a solution for it, on one of the lowest levels.

EXAMPLE

Software for a farm. You'll need to keep track of your animals, vegetables. You need a module for feeding the animals and one for Selling the animals and vegetables to the consumer market.

This could be splitted in a the following solutions

Back-end

• Sell Module: Everyting for selling your products
• Buy Module: Buying seeds, food for your animals, other products, ...
• Sheduler Module: Trigger events for sow seeds, harvesting, ...
• Prediction Module: Predicting harvests quantity's by the weather, and market prices, ...
• ...

Each of these back-end modules, can have it's own Data Access Layer, DTO, WCF Services, ...

This solution will only contain Business Logic, Data Access, ... . And there can be multiple front-end solution connecting to these back-end solutions.

Front-end

• ASP.NET MVC Application: Webshop for selling to a consumer
• WPF Application: Approving sells
• Other WPF Application: Buying things.
• Mobile application: Getting the events to your phone or something.
• (Another option is to connect 2 or more backend solutions into 1 front-end solution)
• ...

This is a BIG change for your project and this will have an impact. Make sure you think this true, if you wan't to change it.

Multiple solutions will INCREASE your overall Build Time and it's important to have a nightly build so every developer can always work on the latest binaries, without having to build all the solutions on his local machine.

Note you can still use your layers in the different solutions:

• Infrastructure Layer
• Integration Layer (External Systems)
• Domain Layer
• Repository Layer
• Manager Layer
• Service Layer

---

To make this work all together and don't get messed up with binaries. You can map a drive I.E. X: where you have a folder binaries, where you have a folder for each solution. where each solutions copy's the assemblies on the post build event. (Script this, so it works on every machine)

If you have a good network infrastucture, you can also copy it on a server. So when you build all solutions for example in TFS, it can copy it to a location all developers can access.

If you build in TFS make sure your build order is correct, first the lowest layer, last the highest layer.

But as you split up your solution, in solutions you'll probably don't need them in every solution.

I recently read an article about Onion Architecture, maybe you can have a look at that too. (It's specific for ASP.NET MVC).

You can also have a look into CQRS.

Answer 2

Why 80+ projects while you only have 6 layers in your application ?

You might answer that they cover a large number of functional areas, but do you need all these functional areas in one solution in the first place ?

I'd recommend reflecting architectural divisions with projects and functional divisions with solutions. Different solutions can reuse the same projects. This way you'll have one project for each reusable architectural layer and as many Domain projects as there are functional areas.