Typical rule of thumb for dividing pieces of code into seperate projects

I'm wondering when to divide code, and components of a project into a separate project. I'm creating a MVC .NET Web project, and there are many directories/sub-directories, and I haven't even started getting into some of the background processes that will take even more space.

I'm just trying to work on organizing projects and the code-within.

When 开发者_如何学Cshould you start dividing your code into separate projects? Could you also provide an example?

Thank You

I often see a variation on something along the lines of:

• Web App
• Service Layer
• Business Layer
• Data Layer
• Unit Tests
• Integration Tests

One way to get an idea is search for asp.net MVC open source projects and see how they are doing it.

For an alternate way to above you can check out CodeCampServer. They used the Onion Architecture to layout their projects.

The Onion Architecture is different than what was laid out above and they have a great explanation of why (webcast).

Pictures taken from web page referenced above.

Key tenets of Onion Architecture:

•The application is built around an independent object model •Inner layers define interfaces. Outer layers implement interfaces •Direction of coupling is toward the center •All application core code can be compiled and run separate from infrastructure

The Onion Architecture link with the open source sample gives you reasoning behind when/why and a concrete example to play with to see if you like it.

Most often in my apps, the purpose of separating code into different projects is to accomplish code reuse. There aren't any hard-and-fast rules, really, but here are some principles I try to follow.

For code reuse, I consider whether a class I write is usable in a different context. For example, if I have an ASP.NET website that communicates to a database, the data access code might be reused in a windows-based application, so it is a good candidate to factor into its own library.

I create extension methods for convenient manipulation of strings, streams, or other common things. These, I factor into a library for common use across all applications.

In summary, try to organize your projects into highly-cohesive collections of related classes, and avoid creating do-everything projects. You'll find that the highly-cohesive projects are more likely to be reused, saving you time and your employer money.