Looking for Good Summary on Organizing Win Forms Solution

I am in the planning stages of rewriting a fairly large Access app into C#/SQL Server using VS 2005.

With forms, reports, datasets etc there will be hundreds of classes, so I am looking for a best practices way to split the solution into projects, and am looking in general for guidelines on organizing solutions.

None of the books I have seen at Border's so far cover this very well.

Any suggestions along these lines would be greatly appreciated.

Thanks
Mike Thomas

Visual C#11

For the most part, this is a design issue. If you want to create a class library you obviously have to create a separate project, for example.

Semantics aside, from a usability standpoint, Visual Studio is known to have issues with solutions with many projects and many files. There's no one recommendation (or set thereof) that I've seen to quash this issue; but some things I find useful:

Planning projects around specific development groups (beyond just a particular namespace) helps to partition work. For example, the Configuration namespace in the framework is contained in more than one assembly. This also allows project files to be "unloaded" by individual developers that aren't going to modify them--reducing much of the stress the Visual Studio issues cause and reduces build times.
Unload projects that aren't currently being frequently changed.
Don't have too many files in one project (yes, that's arbitrary; I would try and keep each assembly under 30 files--but that depends on your hardware).
Ensure all project files are in subdirectories beneath the solution file. Visual Studio doesn't support source code control of projects (and files, I think) above the solution's directory hierarchy. If you want to have solutions that have a subset of projects in another solution make sure the solution with a subset of projects is in a subdirectory of the solution with the complete set...
From a deployment aspect, the red-bits green-bits model that Microsoft uses mandates that once released an assembly should change only in exceptional cases. If something needs to be added to a namespace it should be put in a new assembly. If you think you might want to follow that model you can organize your projects accordingly.

Hi,

I think Peter overemphasizes VS problems with large projects. I've worked with pretty large solutions and projects without other problems than slight slowdowns.

I'll describe how I organize my projects.

First of all you need a Shell project which is the backbone of the application and offers services to the different modules of your application.

Next you need a data layer project which encapsulates interaction with the database. Here you can choose a strongly-typed datasets, a generated DAL, etc. You can break this project in different modules around business areas if needed.

The third project should hold all the business logic of the application. Data manipulation is done here. You can break this project in different modules around business areas if needed.

Then you need another project for the reports and finally you have a UI project (which may be split) which contains user controls and the forms that the application uses.

For large projects, I usually have tables in the database to dynamically build the shell's UI. For example, the database could contain a Admin.Forms table which the shell reads to build a tree of forms on the left side of the main window. When a form in the tree is double clicked, the shell creates a new instance of the form with the name of the type (a field of the table) and adds the form to a tab control for an MDI look easily implemented.

I hope this helps,
Charles

"known to have issues" I don't know how under emphasizing I could be :-). But, really, there's nothing worse than having to re-architect a solution's organization to get around a issue in Visual Studio.... And if you've already released some or all of the assemblies, this is almost impossible.