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

Alright dear readers (both of you), I told you last time that I would answer that age-old question, “How many projects should I have in my solution?” The answer is: only as many as you need. I know, I know, but it’s not a copout, really it’s not. I’ve really found that is it easier to start with fewer projects and break them out when you need to, than trying to combine projects later on. Does that mean that one project with everything in it is right? Yes. If that is all you need.

I realize it sounds like I am being wishy-washy, but I promise I am not. For the sake of being opinionated (because “as many as you need” is hard-to-follow advice if you are looking for guidance), I will say I normally find that I have three projects. I tend to call them Web.UI, Core and Specifications. For this series we’ll be building a web project, but you could just as easily swap the Web.UI project for a WPF.UI project. Now, if you don’t consider the Specifications project as part of the “According to Hoyle” project, then I only have two projects. 

The thing that I will do is namespace everything within the project n a way that makes it easy to break them into their own project if I need to. So I had my data interfaces in a data folder (with that namespace) and inside that a folder for each type of implementation (e.g. an NHibernate folder, a SubSonic folder and an Entity Framework folder). This sill allow me to make a new project called Core.Data.NHibernate and move those files over and hopefully not break anything (I haven’t needed to do that yet).

I have been using this project structure for a while and am pretty happy with it. It came from stealing little ideas from respected developers around the community, and hashing it out with my co-worker, Troy. He is the one who kept reminding me that I didn’t need all those projects in the solution, and eventually we whittled it down to these three.

One thing that I will also do, is have my Specifications project a folder above the location where the Core and Web.UI projects are in the file system. I stole this Idea from Sharp Architecture and it makes for good, solid separation of the Specifications from the rest of the production code.

I hope this gets you ideas flowing for your own solutions and gives you a jumping-off point for deciding just what your solution needs in it. This should also be a good way to get the (civilized) conversation going about your won project structure within your team.

Next time, we’ll talk about tools. We’ll briefly discuss why you would use each tool and what comparable tools are out there. We’ll look at application architectural patterns (MVC vs MVP vs MVVM vs Web Forms), ORM tools, IOC containers, mocking and testing frameworks and some helper libraries that might make it easier to do some things within your own project.

Posted on Sunday, September 13, 2009 7:20 PM | Back to top


Comments on this post: Let’s Build A Dev Shop (Part 4 of n)

# re: Let’s Build A Dev Shop (Part 4 of n)
Requesting Gravatar...
As close to a perfect solution arrangement as I've seen. Bravo.
Left by Troy Tuttle on Sep 14, 2009 1:04 PM

# re: Let’s Build A Dev Shop (Part 4 of n)
Requesting Gravatar...
interesting article
Left by activekita on Mar 24, 2010 2:41 AM

Your comment:
 (will show your gravatar)


Copyright © Lee Brandt | Powered by: GeeksWithBlogs.net