What are some standards to follow for organizing a solution?

Question

I have been working on an in-house management application that has tools to help automate various aspects of peoples' work. The solution currently contains around 40 distinct forms that serve different purposes.

I was wondering if there are any industry standards I should follow for breaking up the solution into individual projects/solutions. Should I just keep all of these forms as part of the root solution?

I would like to reorganize before adding any more functionality because it just feels like bad practice and I would like to refine my approach to overall design when it comes to large solutions.

Some cursory google searches turned up some results for separation of different layers in regards to web services (Data access layer, server, client etc) but this application is currently only used on desktops.

I don't have high enough reputation to post images, but the current organization has all of the forms at the root level of the solution and are simply a list of them in alphabetical order (as would be expected) like: frmAddEquipment, frmAssignSoftware, frmBackupReports, frmContacts, etc, etc

Answer 1

Even in a desktop application, you should have layers. Separating your application into data access, business logic, and presentation layers will impose structure and architectural constraints on your application that will increase re-usability, supportability, and testability.

This of course assumes that you have used a layer-based architectural pattern. If you have not, and all of your data and business logic are all captured in your forms, and replicated over the various forms, then you likely have what we call a " ball of mud " architecture, and have to make some serious decisions. You can either

1. refactor your application to a target architecture or
2. accept that you have built a disposable application, and continue on your current path.

If you decide to refactor to a target architecture, it's patterns will generally imply a solution to your question. It will have components that will naturally allow your application to fit into various projects. If you choose to stick with the ball of mud, no amount of renaming or project splitting will really help, you will just make a complicated solution more complicated with arbitrary rules, so you might as well keep it simple.