Advice on seperating projects in .NET

Question

Hi All

I’m looking for some advice on separating projects in .NET. I’m building a large windows form app (80 tables) and I’ve only got a couple of projects. They’re becoming quite big. I noticed the problem when I saw the list of references the other day. This is the first time I’ve create an application this big, so the naming of projects and their separation is becoming a little confusing.

Here’s what I’ve got, and the concerns of each project.

ProjectName.Dal (data access, this is auto generated for me, I don’t touch it.)

ProjectName.Bll (repositories, communicating with web services, generating emails, generating excel and word documents)

ProjectName.Model (domain objects)

ProjectName.UI (windows forms and user controls)

ProjectName.UI.Web (some web pages for a small web interface for the system)

ProjectName.UI.Controls (generic custom windows form controls)

ProjectName.UI.Presenters (a couple of presenters for MVP forms)

ProjectName.Reminder (a web service for the application which reminds people to do things)

ProjectName.Tests (Handle all unit tests) - I'm not sure whether each project should have a tests project, e.g. ProjectName.UI.Presenters.Tests

Answer 1

One thing that I like to separate out as a separate assembly from those you have already mentioned is a 'proxy' project.

Let's assume you are consuming one of your webservices in your presentation tier. Instead of directly referencing the service (wcf/.asmx) in the presentation tier, I like to have a separate project dedicated to encapsulating the proxy to that service. I typically have a wrapper class around the proxy itself to help manage faults and making sure the proxy is always available to the presentation tier (or giving good exceptions if not) and also provide nice presentation tier objects out of the proxy. For example, I might want to pass Widget[] instead of a DataTable of widgets from my service to my proxy to make it all nice and SO-compatable (obviously we don't want to pass DataTables out of a service since they are all but incomprehensible at the .xsd level) But DataTables are nice to bind against in the presentation tier so I wrap the actual proxy that is getting that widget[] with a 'managedProxy' that does the conversion from the array to the DataTable as well as manages the proxy call. Having this separation of the proxy fom the presentation tier at the class level is then taken a step further by pushing it into it's own project. That makes it more portable for moving to the next pres tier of the moment.

Answer 2

As far as I can say, that's way too much separation.

I think that the best structure would be something like:

• ProjectName.Dal
• ProjectName.Bll
• ProjectName.Model
• ProjectName.UI
• ProjectName.Reminder

The tests can be included for each project it targets, in a separate folder/namespace, but that's subject to yet another debate.

Seriously though, having too many projects within one solution not only slows down your machine, but compromises your sanity for nonetheless coupled objects that work together anyway.

Answer 3

use folders within the projects to further separate your classes from eachother based on domain. Also, you can create solution folders in Visual Studio, these are virtual folders that can be used to group projects within you solution. Right click on the solution in the solution explorer, and create a tests folder, as an example, and you can put test projects in there, setup projects into another, etc, etc... You may want to break up other domains as well.