Reputation: 15817
I have inherited a large project, which consists of an ASP.NET application and a VB6 application.
I am trying to refactor the code as I go along. My question is: what guidelines are there for splitting a single project into multiple projects? I have researched online and some developers say create separate projects for the Business Logic Layer and Data Logic Layer, however others says have a Utilities project.
What categories of projects do other developers use? I am looking for a list of categories.
Upvotes: 0
Views: 56
Reputation: 11964
If your system is very complex, you can split it to multiple projects by subsystems.
Steve McConnell in Code Complete wrote:
"Common subsystems:
Business rules: Business rules are laws, regulations, policies, and procedures that you encode into a computer system. If you're writing a payroll system, you might encode rules from the IRS about the number of allowable withholdings and the estimated tax rates. ...
User Interface. Create a subsystem to isolate user-interface components so that the user interface can evolve without damaging the rest of the program. ...
Database access. You can hide the implementation details of accessing a database so that most of the program doesn't need to worry about the messy details of manipulating low-level structures and can deal with the data in terms of how it's used at the business-problem level. ...
System Dependencies. Package operating system dependencies into a subsystem for the same reason you package hardware dependencies. If you are developing a program for a Microsoft Windows, for example, why limit yourself to the Windows enviroment? Isolate the windows calls in a Windows-interface subsystem. If you later want to move your program to Mac OS or Linux, all you'll have to change is the interface subsystem."
You can also separate out sonamed Common project that usually is created to tear cycle references and contains common interfaces and utilities of solution.
Upvotes: 1