What is the optimal way of organizing a C# project?

Question

I was wondering here, how do you guys organize your projects, in terms of functionality, scope, etc.

Do you have one project for unit tests, one project for class library code, one project for User Interface?

Or do you just divide all these into separate folders?

I was thinking that separating these by projects is easier, because your central code library is at one place, without direct references to the UserInterface (no WinForms dependencies) or the UnitTests.

Any opinions?

Answer 1

I try to divide projects into what you might call "deployment units." In other words, "How might I deploy these assemblies?"

Because I'm obviously not deploying unit tests, they are in their own project.

I then divide UI and "business logic" into separate projects. If I keep those lines of separation clean, I can replace my UI layer with a new technology or infrastructure (think WPF vs. ASP.NET) and still reuse the "business logic" assemblies for both. I just introduce a new UI layer that understands the business logic interface.

I also try to keep a separate library for code that I might share between solutions. This would be my data access utilities, file parsing utilities, and others that I use over and over as I build projects. I can just include those assemblies into my new solutions and I get all of that functionality that I've already invested my time in.

Hope that helps.

Answer 2

A few patterns I've found useful in organizing projects within a solution:

I almost always have a "common" or "utils" project. This project should have very few dependencies, so it can be easily re-used anywhere and everywhere in my solution (or possibly in other solutions). You be surprised how many little helper classes will fall into this project.

I always try to separate my business logic into one project (or more likely a set of projects), and my bootstrap/provider code into a different project (or set of projects). My bootstrap/provider classes are context-specific (they can assume the presence of an HttpContext or command-line args, etc.), but they contain no business logic. My business classes implement the business logic, but do not assume the presence or absence of any context-specific elements. That way, if I initially build the system as a console app, I can later write a set of windows-service bootstrap/providers, and very quickly transform it into a windows service with minimal-to-no impact on the business classes.

Similar to bootstrap/provider classes, I also try to isolate my data layer from my business classes. But that's a common, basic separation that everyone has heard 1000 times, so it's hardly even worth mentioning.

Many systems' business logic is too complex to fit into a single project and keep a degree of code maintainability. Thus, I usually find myself with multiple business logic projects, grouped by functional area ("customer mangement", "product inventory", etc.).

Answer 3

Last few projects I've been involved in - we ended up with the following structure (All WPF Prism projects):

xxx.Shell.Exe

xxx.yyyModule.dll (x 4-7)

xxx.Tests

xxx.Model

xxx.Common

And for those that use WCF - add:

xxx.Backend

xxx.DataContracts

All in one solution (we live with the long build-times...) Dividing it up into seperate solutions introduced too many problems when refactoring. So far - it has worked great for us.