Best practices for setting up an "enterprise" project in Visual Studio?

Question

I am preparing for the development of an enterprise-style application for a very small business of 6 employees (including myself -- before you question why a 6-person company would need an enterprise application, we have a lot going on with a lot of processes and tools needed to simplify it). As always I'm trying to follow best practices in setting up the project; I'm going to be using .NET 3.5, with the database being on Windows Server 2003/SQL Server 2005.

While I'm developing and testing the solution, should I have everything in my main project? What I mean is... Visual Studio 2008 Professional lets you have "database projects" as well as all of the other types of projects. For this application I'm going to need:

• Database Project containing the create and test scripts for the new data schema
• C# projects containing the actual code/application:
  1. Customer-facing web site(s) using ASP.NET MVC
  2. Back-end order processing system, probably web-based but possibly a "smart client"
• SSIS project containing packages to ETL the "live" application data provided by our vendor(s) and migrate over existing customer and order data from the legacy database.
• Reporting project for SQL Server Reporting Services

Basically, I am wondering if it's a good idea to have all of these as part of one massive Visual Studio solution (let's call it "EnterpriseSolution"), or if I should break them out and tackle them separately. Most of the books and websites I've looked at include them all together, but they also assume a team of developers, DBAs, architects and the like - in this case I'm all of them rolled into one. The database project and at least some ETL processes need to be done and loaded into production before the rest of the application is written, since we need to load the new vendor's products in a live environment (to start selling them).

I'm a little overwhelmed as to how I should begin to structure this, but I want to come up with an overall plan before I begin to lay things out and start coding.

Any suggestions on how to tackle a project like this?

Answer 1

What I have done is create separate solutions for every independent piece of the project and then start integrating them into more complex solutions. This way you could load just part of the application for unit testing or debugging.

For example, in a multi layered application, I would create an independent solution for the data layer and a unit test project. Another solution would include the data layer and the business objects layer working together with unit testing. The complete solution would include the mentioned above projects plus the UI project

This way I can load and test separately every part of my application.

Answer 2

I like to start with a single solution until its gets so big that build times are noticeably slow.

How you do this really depends how the different parts of the system will interface with each other. The easiest way is to adopt a service oriented architecture. Then each service can have a different solution and the frontend its own solution.

However I really would reccomend that you strat with one solution and only make things more complicated when it is neccesary. Its nice to be able to build everything with one click.

Answer 3

There is no reason the application can't be all in one, if you need to breakup elements you could do that later on, as long as you keep your objects loosely coupled.

The one nice aspect of having separate projects is that you can successfully compile a section while having other sections incomplete, by just unloading them.

Answer 4

I would recommend creating a "Blank Solution" to start that would be a *.sln file (Say EnterpriseSolution.sln) that would sit in a folder named EneterpriseSolution. A blank solution can be created from "Other Types". I would then add in the additional parts you described as seperate projects, each within its own folder under the "EnterpriseSolution" folder.

For instance, each of your client facing websites would each have their own project folder. It looks like you will have more than one website so you will need to make sure you setup different "ports" for each to run under if you use one solution wrapper. However, you can aslo create different solution "wrappers" (as a blank solution to start and then project reference the projects you want) to include each website sperately in your folder structure so you can focus on a portion of your enterprise solution. But physically you will know where everything is and how it is organized.

This way, when you look at your Enterprise Solution folder thru windows explorer the only thing you will see is your solution file(s) and your project folders.

Thanks and good luck with your project.

Answer 5

First off, the Database Project is great stuff, and I would highly recommend using it for your data layer.

I would separate by project as it makes sense, but keep it all in the same solution.

Answer 6

It's definitely good idea to use one Solution with several projects in it. If you want to use ASP.NET MVC define one C# Project for each layer: MVC Web, Service layer, Data Access Layer and separate test project. You can learn from Rob Conery's Storefront sample application or Oxite.

You can try also to use Guidance Packages from patterns & practises group:

http://msdn.microsoft.com/en-us/practices/default.aspx

Answer 7

I have found it most convenient to maintain the client-side and server-side code in separate solutions. This assumes the server presents a stable interface such as a web service or WCF interface.

Over time things grow, you may use more than one client technology (Windows, web...) and keeping these clusters of technology separate in their own solutions keeps things simpler.

If you are looking for a good architecture sample see the Northwind Starter Kit at CodePlex. I found this when reading "Microsoft .Net: Architecting Applications for the Enterprise", by Dino Esposito and Andrea Saltarello.

The Northwind Starter Kit is a sample application produced by Managed Designs (http://www.manageddesigns.it) and intended to be used as a blueprint when designing and implementing a .NET layered application architecture. The application uses the standard Northwind database, as included in Microsoft SQL Server and Microsoft Access: no modifications to the database schema are required in order to install and run the starter kit.

I agree with @Chris Ballance that including a Database Project can be very helpful. But note that the DB Project can seem a bit complicated as it syncronizes the project and reference DB structures.

+tom