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

I move code to a new project, if it has general functionality (theoretically) usable by other projects too. If the project is large, because it represents a complex problem, then namespaces provide a great way to bring order in the code. Here you can for example introduce a (sub-)namespaces for each SQL table, etc. etc.

Answer 2

Projects should be cohesive. Logic should be related, and accomplishing a similar goal

This answer will depend on the size of the product you are supporting. In general we organize our projects along domain and logic. And we will divide those even further, the more you divide the more organize you must be, or you are going to hit the dreaded recursive dependency issue.

When I do choose to break up project it is when it grows to be too large or two areas are becoming too similar.

When complexity is rising I do not split by tables, i generally split functionality.

Re-usability is another excellent time to reduce lines of code, as well as introduce a new project. However be careful how many "utility" libraries you introduce because they do have impact on readability/understandability.

I do not think there is a line in sand that says, if you hit 3k SLOC, you have too much. It all is contextual.

Answer 3

I always have several projects (and therefore a solution) , instead of one project with all of my source in it.

In some cases, it is unavoidable because you are using and open source library and want to be able to debug it. But more pragmatically, I typically have my applications provide functionality via plugins. This allows me to change the behavior or offer a user-selectable behavior at runtime. In the non-plugin case, it allows you to update one portion of your program without updating everything. There are also cases where you can provide the main apparently, and only download the modules / assemblies when you need them.

One other reason is that you can create smaller test apps to exercise an assembly, rather than building a very large solution and potentially requiring a user to execute several (and irrelevant) GUI operations before even reaching the part you want to test. And this isn't just a testing concern -- maybe you have less-savvy users in your organization that only want to be presented with the bits that concern them.

Answer 4

When the overall purpose of the project remains the same, but the number of classes is becoming large, I tend to create folders and namespaces to better group functionality within the project. Classes that are coupled to each-other tend to go in the same folder/namespace, so that if I need to understand a given class, the related classes are nearby in the Solution Explorer. I usually only create new projects if I realize that a particular piece of functionality is very different in purpose or if there is a common dependency between existing projects.

I usually wind up with a few relatively small Framework projects that define interfaces for loose coupling between other projects, with larger projects for the different types of concrete functionality. That's always at least one project for the UI and one project for logic and data (often split into two projects if the data layer becomes very large in its own right.)

Answer 5

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.