When do you decide to split up large projects into smaller projects?

Question

When/where do you decide to split a large Visual Studio project into smaller multiple projects? If it can be reusable? when project is too big? (but how big is too big?)

and When you do split the project, do you,

• group by database tables

• group by similar functionality

• other..

Answer 1

Pros of many projects:

• Easier to isolate code for unit testing. I like to isolate code that has a dependency on a big external server thing, for example code that talks to the SMTP server gets its own assembly, code that talks to the database gets it's own assembly, code that talks to the webserver, code that is pure business logic like validations.

Pros of few projects:

• Visual studio goes faster
• Some developers just don't get your vision about dividing up responsibilities and will start putting classes everywhere, so you end up with the pain of extra projects and the benefits of putting everything into one project.
• Each project has a configuration and when you make a decision about project configuration, often you have to make the same chagne everywhere, such as setting or changing the strong name key

Pros of many Solutions

• You hit the maximum project level later.
• Only the stuff in your current solution gets compiled everytime you hit f5
• If the project isn't expected to change in the life of your application, why re-compile it over and over? Call it done and move it to its own solution.

Cons of many Solutions

• It's up to you to work out the dependencies between solutions and manually compile the dependencies first. This leads to complicated build scripts.