.NET project splitting guidelines.
I need some advice on splitting projects in .NET. Im building a large window form attachment (80 tables) and Ive only got a few projects. They get pretty big. I noticed the problem when I saw the list of links the other day. This is the first time I've created an application this large, so assigning projects and separating them becomes a little confusing.
This is what I have and the problems of each project.
ProjectName.Dal (data access, this is automatically generated for me, I do not touch it.)
ProjectName.Bll (repositories, web services communication, create emails, create Excel documents and documents)
ProjectName.Model (Domain Objects)
ProjectName.UI (Window Forms and Custom Controls)
ProjectName.UI.Web (some web pages for a small web interface for the system)
ProjectName.UI.Controls (Common Custom Windows Forms)
ProjectName.UI.Presenters (MVP Presenter Pair)
ProjectName.Reminder (a web service for an application that reminds people to do something)
ProjectName.Tests (process all unit tests). I'm not sure if every project should have a test project for example. ProjectName.UI.Presenters.Tests
One thing that I like to stand out as a separate assembly from the ones you already mentioned is the "proxy" project.
Let's assume you are using one of your web services in your presentation tier. Rather than referencing the service (wcf / .asmx) directly in the view layer, I like to have a separate project dedicated to encapsulating the proxy for that service. I usually have a wrapper class around the proxy itself to help handle errors and make sure the proxy is always available to the view tier (or throws good exceptions if not) and also provides good presentation tier objects from the proxy. server. For example, I might need to pass Widget [] instead of DataTable from widgets from my service to my proxy to make the whole thing nice and SO compatible (obviously we don't want to pass DataTables from the service as they are all but incomprehensible at the .xsd level) ... But DataTables are good for binding to the presentation layer,so I wrap the actual proxy that receives this widget [] with "managedProxy" which does the conversion from array to DataTable and also manages the proxy call. After this proxy splitting, the class-level presentation layer then pushes further, nudging it towards its own project. This makes it more portable to move to the next level of time.
source to share
As far as I can tell, there is too much division.
I think the best structure would be something like this:
- ProjectName.Dal
- ProjectName.Bll
- ProjectName.Model
- ProjectName.UI
- ProjectName.Reminder
Tests can be included for each project it targets in a separate folder / namespace, but this is up for discussion.
Seriously, while too many projects within a single solution not only slows down your machine but also compromises your sanity, there are nevertheless related objects that still work together.
source to share
use folders in projects to further separate your classes from eachother based on domain. Alternatively, you can create solution folders in Visual Studio, which are virtual folders that you can use to group projects within your solution. Right click on the solution in Solution Explorer and create a test folder as an example and you can put test projects there, set projects to different, etc. Etc. You can also split other domains.
source to share