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.
Best Answer
OK, I think you are missing a layer which would make your problem easier to solve
I would have:
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