Sitecore Multisite Best Practice for setting up Visual Studio Project

Question

I'm seeking an advise on best practice that has worked for creating a asp.net MVC visual studio solution that supports multisite (multi tenant). One thing we would like to do is minimize the regression defects so that developer don't modify the wrong website code base etc.

in my mind there are 2 approaches.

Approach 1:

-Services (Project)
    |- Site A
        |-Service.cs
    |- Site B
        |-Serviceb.cs
|-Repository(Project)
    |- Site A
        |- Repository.cs
    |- Site B
        |- Repositorya.cs
|-MVC (Project)
    |-Areas
        |-Site A
            |- Controller
            |- View
        |-Site B
            |- Controller
            |- View
    |-Content
        |-Site A
            |- CSS
            |- JS
        |-Site A
            |- CSS
            |- JS

Approach 2

-Services.SiteA (Project)
        |-Service.cs
-Services.SiteB (Project)
        |-Serviceb.cs
-Repository.SiteA(Project)
        |- Repository.cs
-Repository.Site B(Project)
        |- Repositorya.cs
-MVC.SiteA (Project)
        |- Controller
        |- View
        |Content
            |- CSS
            |- JS

-MVC.Site B
        |- Controller
        |- View
        |Content
            |- CSS
            |- JS

Could someone please help me with which option may be better? Not that the solution needs to support more than 8 web sites.

Answer 1

I have got one more alternative to address that. Currently working on a huge project, with dozens of developers and quite bureaucratic process of deployments, we have introduced the following approach:

1. Project consists of multiple logical subparts, which in fact are individual websites.
2. Each of those websites we set up as an MVC Area with own controllers, views etc
3. Most important - we set up MVC Areas as individually pluggable DLLs. So each of that websites is a separate project under solution, with its own resources and statics; on build everything is copied under their required paths and DLL goes to the \bin folder.
4. One more class library for shared (by all websites) resources, it is being referenced only by those sites, that need that functionality
5. In Sitecore, we have the same strict principles - the content, layouts, renderings are isolated as higher as possible, no individual content may be re-used (unless from shared resources folder).

This approach serves us almost a year already and has proven for its agility, much easier deployment and fairly less code merge conflicts. If you are working under just one site - you don't need to re-compile and re-deploy everything - just replace one dll at bin folder.

Thus, combining that with your question, Approach 1 would be an answer.

References (more to read):

Sitecore MVC areas as pluggable separate DLL - making areas further more independent

Sitecore with MVC Areas as pluggable Module