Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code

I have looked at others' strategies for arranging projects within a solution, and I have experimented with my own until I cam up with the following (mostly based on my own OCD about organization, but somewhat based on actual development reasoning).

I must preempt by saying that I am using the MVP pattern for my projects, so that influences my arrangement somewhat. I will also say that I enjoy using periods in my project names. Mostly because it looks clean to me, but also because I have a need sometimes for using projects in multiple solutions. This need led to several decisions that some people may not agree with. when deciding what things go in a particular project, I useProjectStructure that as my guideline: If I have to move this project to another solution, will I need to take this with it? I may have a data and domain project that is called [CompanyName].Data and [CompanyName].Domain and use those in three or four different solutions for different software I develop for them. Then I may have a [ProjectName].NHibernate.Data project in that solution as well.

First, I have four basic projects: [ProjectName].Domain, [ProjectName].Data, [ProjectName].Presentation and [ProjectName].UI. The Domain project is my business objects and logic layer. anything that has to do with the business domain of the project and will only be used with that project. The Presentation project has my presenters in it (pretty straight forward). My Data project is the Interfaces that my presenters will use for data access and will get its implementation from a project with concrete classes in it. Finally, my UI project contains the interfaces that my presenters will use to display data. I will have one or more projects that contains concrete implementations for these interfaces.

I will add test projects for each of these. At first glance, this seems like an inordinate amount of projects in a solution. I've seen lots of developers add one project called UnitTests to a solution and have folders organizing the unit tests for each project. That's not bad, but what if I need to take that project to another solution? I want to take the unit tests for it with me, but I don't want to take ALL the unit tests with me, so that VSProjectStructure won't work for me. I could also add a UnitTests folder to each project. This is a little bit better. It would definitely cut down on the amount of projects in my solution. The problem I have with it is that tests are supposed to simulate how a user or another object interacts with that object or interface. With my tests INSIDE my project, I might get a test that passes because it is within the same assembly as the system under test (SUT). I choose to make separate assemblies for my tests to give myself greater confidence that the SUT will work as expected when I am ready to deliver the software (and that's what TDD is all about). I also use a Solution Folder to organize my test projects away from the code projects. This is only due to my own OCD and the ability to collapse the folder and only look at the code projects in the solution.

Now there are some things I don't like about my organization, but I haven't found a better solution (here's where you come in). I'll have a concrete Data project (e.g. [ProjectName].NHibernate.Data) this will have a test project (e.g. [ProjectName].NHibernate.Data.Test). This LOOKS the same as all the other unit test projects, but this is technically an integration test (testing to see if my project integrates with the database), so it's possible it could use another convention to distinguish it. It may not. I also STILL think there are probably too many projects in my solution (or at least the potential for lots), but every separation has been made for a reason.



Posted on Saturday, August 2, 2008 3:32 PM | Back to top

Comments on this post: On Project Structure

# re: On Project Structure
Requesting Gravatar...
I am right on with most of that. I don't think that Hibernate needs to be separated into it's own project though.

I implement a repository class that takes a SessionFactory in it's constructor. That is somewhere else. It basically does all of the touches to the database. Any calls that need to touch the database go through it. Then I abstract it for unit tests.

So I have the concept of unit tests and integration tests. Any time classes need to touch anything external to the code (and sometimes external to the class itself), those things are abstracted away using mocks and fakes. That is unit testing.

Then we test putting parts of the system together using integration tests. We also test calls to external items (such as databases and config files) in the integration tests.
Left by Robz on Aug 04, 2008 11:44 PM

# re: On Project Structure
Requesting Gravatar...
Good layout. But one way to keep things a little smaller in number is to combine unit test projects into one project, separated by name space until you have the need to break them out. Who knows? You may never have the need to separate them.
Left by Troy Tuttle on Aug 28, 2008 8:50 AM

Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: