We're starting a new MVC 5 project that will ultimately consist of 4 websites depending on the kind of user:

  • One internal, for company employees.
  • One for agents, independent contractors that work for the company.
  • One for external salespeople.
  • One for customers, which could be any one from their homes.

The internal website will have considerably more functionality than all the others, and since it will be only accessed by employees it will be kept in a private network. The solution is structured like this:

  • A Data project where the model classes are kept. This has been done using Entity 6 Database First.
  • A Resources project with strings and images.
  • A Web project with the MVC stuff: controllers and views, plus CSS/JS, etc.

Given that one website will be internal while the other will be accessed through a public IP, my first thought was having two separate solutions: one for the internal web and one for all the other ones (changing between views based on the logged user), deploying them to a different server. The downside I see is that there would be a ton of duplicate code between the solutions: not only the Data project would have to be very similar or even the same, the resources and the views would have a lot of common stuff.

I'm wondering if it would make more sense to have just one solution with a Data project, a Resources project and then InternalWeb and ExternalWeb projects. Maybe even having three different projects instead of ExternalWeb: AgentsWeb, CustomerWeb, SalesWeb.

I have as little experience bulding MVC applications as I have deploying them, so I would like to know which way is seen as best practice for this kind of situation.

  • Two questions: where is your business logic and where is your authentication/authorisiation.
    – Ewan
    Oct 14, 2015 at 11:40
  • My model is in the Data project, where I keep Entity's EDMX and Identity's model classes. The rest of authentication logic is in the Controller and views code.
    – erictrigo
    Oct 14, 2015 at 11:44
  • You can share projects among solutions. So the "duplicate code" isn't really an issue. That is, there won't be two different Data projects. That said, I don't see any compelling reason not to do this in a single solution. Oct 14, 2015 at 13:14
  • @JimMischel Will it be easy to deploy each website separately while having them in the same solution?
    – erictrigo
    Oct 14, 2015 at 13:25
  • I don't see why not. As far as I recall, you can deploy individual projects to different places. Oct 15, 2015 at 1:12

3 Answers 3


OK, I think you are missing a layer which would make your problem easier to solve

I would have:

  • Data Layer - EF, sql client whatever
  • Repository - hides data layer
  • Service Layer/Business Logic - does the actual work
  • Authentication Service
  • Application Layer : MVC website
    • controllers : call services
    • views
    • view models
    • etc

By splitting your business logic away from both the data and application layer you are free to use it over multiple application layers. Classically this would be a website and a windows forms application, but in your case it could be a public facing and an internal website.

Similarly with the authentication layer, by splitting it out you are able be much more flexible with where you apply your user rights. Checking in the MVC websites controller, before calling a service, or in the service itself, or both.

Overall by reducing the amount of code in your website, you reduce the amount of code duplication required if you need to have more than one version of the Website.

In regards as to whether having multiple websites vs one muti-role website is the best choice. I would say that having a single website is the easiest for users, but having two, with the critical functions behind a firewall is more secure and more easy to demonstrate security


The structure may depend on the service of your servers.

If I were you, for quick answer I may check UI pages first which have many common parts or not. If overall pages , functions and features are different by roles, you don't need to worry about making multi server. You have many choices and even you can use only one DB with multi servers. Sometime separating servers is better in terms of management, fault tolerance, security and development.

But if there are many common pages among roles, i recommend you implement managing roles and abilities by customer so that server can display different pages by roles or abilities. You can also separate pages by port or URL that prevents code duplication. It may be better in terms of code-management. You may choose this means if you estimate future additional huge requirements. But the weakness is the benefit of first one. For example, if you have to serve important server like payment, you'd better saperate it.


It's hard to give a firm answer without knowing just how much functionality is going to be shared between each website.

However, you always want to avoid duplication as much as possible.

Ewan's suggestion is worth following: create a separate data layer that handles all the database access and business logic. This is always worth doing, regardless of how your front end is going to be designed.

Next, I would look at creating a single front end, and implement user permissions - add checks to see if the logged in user is an agent, salesperson or customer, then adjust what information is displayed depending on this.

you can always split up pages into multiple files, and include each one as needed depending on the user level. e.g for a Create Customer form, do the following: - CreateCustomer.cshtml - contains all generic fields available to all users - CreateCustomer_agent.cshtml - contains additional fields for agents - CreateCustomer_sales.cshtml - contains additional fields for salespeople

Don't forget you can also change the _Layout.cshtml used on each page, so you can pragmatically change the _Layout.cshtml file used, thereby changing the menu used, or even the whole look and feel of the application.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.