1

We are developing multiple applications for the same company.

The applications are distinct (so not suitable for a multi-tennant app) but there will be lots of shared models, a couple of shared controllers and ideally some shared views.

It is the first time I have had to do this, and wonder if I am approaching it correctly. Here is my plan:

  • Create a DB for the shared stuff, and another (per application) for application specific stuff

  • Each application will have 2 connections in web config

  • Create a DLL from the shared models and controllers. Put this in the /bin directory and reference it in the project. I want this to approximate the way a nuget package might work, and reference the

  • For each app create a SharedApplicationDBContext and a LocalApplicationDBContext, each accessing the respective DB.

Questions

  • Are the above steps the right ones to be taking?

  • Is there any way to include cshtml Views in a DLL?

  • Is it ok to include the Users controller / models in the DLL?

  • Are there any gotchas I should be aware of when sharing code like this over mutliple apps?

I know SO likes specific questions, and this is a bit vague, but I'm a bit out of my depth here and looking for some general guidance as to the right approach to take.

Martin Hansen Lennox
  • 2,837
  • 2
  • 23
  • 64
  • If this question is bad, for being too opinion based, could somebody point me to some existing opinions (or beginners' guides)? Because I have googled this prior and struggled to find a starting point, or any explanation of options and approaches. – Martin Hansen Lennox Nov 11 '15 at 17:23

2 Answers2

1

For what concerns the views, you can include them in a DLL, please read here

For the models it's ok to have them in a different project.

For the controllers you can do it but you must let MVC know where the controllers will be located and you can do it by writing a custom ControllerFactory, please read more here.

Community
  • 1
  • 1
user449689
  • 3,142
  • 4
  • 19
  • 37
1

You've got the general idea, but it needs some tweaking:

  1. Don't fool around with DLLs. If the projects exist in the same solution, then you might as well keep your class library there as well. In which case, you can just do a straight project reference. If you're dealing with multiple solutions then you package your class library as a nuget package and actually install it in each project. Creating a nuget package is easy enough, and you can either install from a local/network path or you can set up your own private nuget repo. This makes it stupidly easy to share resources, and you get the ability to publish updates and see at a glance which projects are running which versions of your class library.

  2. Each app should only have the context that relates to its individual database. The shared database can also use a shared context, which would be contained in your class library. You should also house all your migrations related to this shared context in the same class library.

  3. You can include views in a class library, but not as cshtml. They have to be compiled into the class library. You'll need RazorGenerator to accomplish this.

  4. It's 100% okay to include the models related to users in your shared library. However, the controller is trickier. Unless you set up an SSO server that will alone be responsible for handling all authentication (a non-trivial task to say the least), each application will need it's own controller for authentication tasks. If all of the sites will reside on the same domain or subdomains thereof, you can easily share the auth cookie between them. However, if they will reside on entirely different domains, you can still share the same "users", by virtue of using the same database for each, but each site will require a separate login process (logging in at one does not log you in at another, even though the same credentials would work for both). The only way around that is, again, SSO.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444