Best practices for setting up an “enterprise” proj

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

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

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 2

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 3

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 4

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 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

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