views:

125

answers:

2

I'm writing a pretty straight forward ASP.NET MVC web app: only a couple of CRUD pages, some folders where clients can browse documents and just 3 or 4 roles. The website will be used in a B2B scenario, where every client will have their "own" website.

At this point, the only thing that will change in the website, from client to client is the content (ie. the documents, and the rows of data they'll see). If this is the case, what's the best way to manage roles across all of my clients? I'm looking for the simplest possible solution because this is a proof of concept and I don't want to invest a lot of time right now.

What if it's not just the content that changes? Maybe some clients will want a few custom static pages. At this point, is my only option replicating the entire website? I'm leery of this because it'll become hard to maintain if I get a lot of clients.

I'd appreciate any help... I just don't want to shoot myself in the foot; I'm sure someone has done this before.

A: 

I'm not sure if this answers your question completely, but as far as maintaining custom "static" pages I found myself implementing a system on a client's MVC website where the client can create "Pages" from their admin control panel and each Page has a collection of "PageContent" entities which consist of a Title and and HTML content field (populated using a WYISWYG editor). Upon creating a page the MVC application maps http://yoursite.com/Page/Page-Url-Specified-By-The-User to that page and renders its content there. Obviously, the pages are dynamic, but as far as the client can tell they have created a brand new custom page with little or no effort.

Nathan Taylor
Good idea. My biggest concern right now is role management, however.
Esteban Araya
+1  A: 

I create Virtual Directories in IIS for each client, all pointed back to the same folder where my ASP.NET code resides.

This allows me to support several dozen nearly-identical "web sites," each with their own database that is basically identical in form, only differs in data.

So, my site URLs look like:

 http://mysite.com/clientacme/
 http://mysite.com/clientbill/
 http://mysite.com/clientcharlie/

There are two key implementation details I worked out for this:

  1. I use the Virtual Directory folder name to determine which DSN my code reads from. This is accomplished by creating a simple static method that injects the folder name into a DSN string template. If you want to use the same database to store everyone's data, you can use the folder name as a default filter in your queries.

  2. I store the settings for each web site (headers and footers, options, links to custom reports, etc.) in a simple "settings" table in each database (key, value) rather than in the web.config (which is shared). This allows me to extend the code base over time to customize the experience for each client without forking the code.

For user authentication, I use Basic authentication, and I keep usernames, passwords, and roles in a table in each database.

The important thing is that if you use different SQL Server databases for each client's content, you need to script any changes to your database tables, indexes, etc. and apply them across all databases at the same time (after testing of course). One simple way to do this is to maintain an Excel sheet with a table of database names and a big "SQL" cell at the top. Beside each database name, create a formula to "USE databasename;" and then concat the SQL code at the top.

richardtallent
Although I like the idea, I think having to maintain multiple DBs is actually harder than maintaining multiple sites. It's definitely worth considering, however.
Esteban Araya
You only have to maintain multiple databases if you really need to (I do). The same thing could be accomplished with a single database, just use columns to identify which site a particular row of data is associated with, and filter the views based on the folder.
richardtallent