8

I created a solution a while ago that contains a Web API 2 project (provides JSON data to mobile devices) and a Class Library (includes my data access services).

The Web API project uses Ninject for DI and everything works fine.

Now I need to add a separate MVC project for a few web pages. The api should be accessible from www.example.com/api/controller, while the website should be accessed through www.example.com/controller.

The problem is that each of these two, has a different "Register" method with seemingly incompatible route collections. If I set the MVC project as the startup project, routes for the api are not registered, and vice versa. If I set "Mutiple startup projects", they run on different ports which is not my cup of tea.

How I can set the MVC project as the startup project, while registering all routes for both of them?

One more thing. Because the Web API project was created sooner, Ninject configuration has been written inside it. Of course, some of the services from the Class Library project are needed inside the new MVC project. Do I have to move Ninject configuration to the MVC project, or they just work because they are run on startup of the Web API Project?

Delphi.Boy
  • 1,199
  • 4
  • 17
  • 38

2 Answers2

15

This 2 projects are independent from each other like 2 different applications even if they are in the same solution.

To succeed what you try to achieve you have to:

1) Deploy your MVC project to www.example.com (main virtual application).

2) Deploy your WebAPI project to www.example.com/api (api folder is a virtual application). Don't forget to remove api from your WebAPI routes (other wise you have to use this route www.example.com/api/api/controller).

Doing this you can acces independently both projects in the same url.

For NInject part, you can register again the services in the MVC project. Another solution will (which i recommend) be to make a class library project and register there the services after that you reference this class library in both projects.

adricadar
  • 9,971
  • 5
  • 33
  • 46
  • NO NO NO God damn. Stop using two frameworks to solve 1 problem. – Phill Apr 01 '15 at 06:40
  • 1
    @Phill, There are two problems. One is providing a back-end for mobile devices, and another is a regular website to show information, etc. So what is your exact suggestion? – Delphi.Boy Apr 01 '15 at 07:11
  • @adricadar, Thanks for suggesting separate virtual applications. Please see this SO answer:http://stackoverflow.com/a/17023924 I'm looking for something similar. – Delphi.Boy Apr 01 '15 at 07:16
  • @Delphi.Boy i look in the answer, i never do that before, i can't help you with that. But from what i read i don't think it's really good to have that kind of separation... (MVC + WebAPI refered from a class library), i prefer the one with 2 virtual aplications, it's an easy solution. – adricadar Apr 01 '15 at 12:25
  • @adricadar So this would mean in IIS, you have 1 site in 1 application pool with 2 different virtual directories? (one the domain name, one domain name + api) – Alexander Derck May 24 '17 at 10:59
  • 1
    @AlexanderDerck That's correct, basically *domain name* will access the *root folder* content and *domain name + api* will access a sub folder *root folder/api* – adricadar May 24 '17 at 13:50
3

What I like to do, is to have the MVC and WebAPI project in two separate projects (separation of concerns) but let them share the same business logic.

I like to utilize the Command and Query pattern. So all commands and queries is located in another solution project, which both the MVC and WebAPI project has access to.

I deploy the MVC project on the www.domain.com path, the WebAPI project on the api.domain.com and enable CORS on WebAPI for the www origin.

janhartmann
  • 14,713
  • 15
  • 82
  • 138
  • 3
    There is no separation of concern. It's 2 frameworks to solve 1 problem. Stop it. – Phill Apr 01 '15 at 06:40
  • 2
    I would argue that, the MVC returns a view with markup, and the web api returns e.g. json or xml. The api can then also run independent from the MVC. – janhartmann Apr 01 '15 at 06:54
  • Yeah except vNext is doing what should have been done to begin with, and had a single framework. There is no more WebAPI since it's not part of MVC. Now that it handles conneg properly like Nancy and other frameworks. The entire separation was stupid and has confused too many people, example is this question and answers. – Phill Apr 01 '15 at 06:58
  • I get that, but we are not running vNext in production yet. Still I would probably be setting up a separate project in vNext for my "api". – janhartmann Apr 01 '15 at 07:05
  • @janhartmann, I have MVC and Web API in two separate projects (just like what you like to do!), but I don't want the `api` subdomain. – Delphi.Boy Apr 01 '15 at 07:14
  • @janhartmann, i am considering doing something very similar to what you brought up, have you implemented a solution yet? any feedback? – Jordan_Walters May 10 '17 at 18:45