Best Application Design for Software As Service

Using ASP.NET MVC3 C# AND MS SQL 2008

I'm developing a Software As Service site. It's a Car Inventory app for Car Dealers. I have a few ideas of the architecture of the site but wanted a second opinion.

Each dealer will be restricted to a layout, but can upload a logo and select some color theme's.

At first I thought about creating separate sites for each dealer, but upgrading would be a nightmare.

So my thought is, one main site which dynamically changes based on the hostname. ie. So if miamicars.carinventory.com is entered, they would see their co开发者_开发知识库lor scheme and logo.

I would have one master database for the users and company settings, but a separate database for each site with the bulk of the data (car inventory, etc). This way I can backup and handle each site's data individually, but the main code of the application would be in one place.

Also, each company would have a directory to store their individual images.

Any feedback would be welcomed.

Thanks

---

Considering these are multiple companies, I would recommend looking into multi-tenant designs. I know that it looks more complex but it helps you to grow the application cleanly as you grow. Here is another blog entry that is pretty interesting about ASP.NET MVC. Here is another interesting on in MSDN.

All in all, it is better if you are thinking about multi-tenancy to start from and grow it based on that. Particularly if you are going on Azure, it might be the only way to make it scalable.

HTH

---

The way I see it from a database perspective you've got these options. Then again I've never written a multitenant application and gremlins surface during implementation.

1. Have a single database (cluster) for all the tenants.

Set up a single database, with master/replica clustering in the future. All tenants share the site, the separation of data is in the data itself.

• Simplify the management of the physical aspect of your application.

• Simplify the coding.

• Hamper scalability.

• Hamper performance (slightly).

2. Have a database per tenant.

Each tenant gets a database, possibly on a different database server.

• Much more of a pain to roll out new sites.

• Simpler to scale since the data will be partitioned naturally. Tenant A usually wouldn't need access to data from tenant B. Unless you're trying to write some kind of aggregate reports, in which case you get to write ugly sharding code.

• Good scalability. If a tenant can consume enough resources you can give them pretty high end dedicated hardware.

As far as the web servers, I'd look into using a custom SessionProvider with memcached or similar and using the servers themselves solely as processors that keep no state.

---

In regards to database have you thought of using a NoSql database?

I am currently writing a very large web app with lots and lots (TBs of data) and am using MongoDb.

Here are some options:

• MongoDb - Very easy to set up and use. Super easy to scale and can do some very advanced queries. Has drivers for loads of languages including .Net.
• Cassandra - Used by facebook. Can infinately scale. Not as rich of a query set as Mongo and I've heard harder to set up but no experience with it.
• HBase - Built on top of Hadoop. Used by Yahoo, open source via Apache. Little more complicated

In regards to other stuff ASP.NET MVC is what I use. Very easy to deploy, and write code fast.