MVC仅作为表示层

Question

I have a WebAPI web service, which acts as a business logic layer for client applications (WinForms and Mobile).

Now I want to create an MVC application which will act as presentation layer only, and I am having doubts weather this architecture makes sense or does it break MVC concepts.

If it makes sence, what is the right/correct way of interaction between MVC application (as a presentation layer) and WebAPI service (as a business logic layer)?

Will appreciate if anyone can give me some code examples.

Answer 1

It's fine if you use mvc this way, your controllers can access the webapi and serve the data to the templates.

You might also consider angularjs as views/templates and the controllers there can call the webapi for data.

Answer 2

While I think other answers are accurate, here is some other concerns you may think of.

First, your WebAPI is probably where your business are implemented. Indeed, you may already deal with:

• Business related exception
• Validation
• Operations available
• etc.

Your Api is what should not change, unless the business rule behind a certain functionnality changes too.

What I want to point out here is one thing: Keep your user interface completely independant from your API

The risk of using an MVC app with a WebApi

All the code together = mutiple reasons to change the same thing

By using an MVC app, you could be tempted to package the WebApi and the MVC app in the same solution. You would also be able to deploy all your stuff together. But doing it this way, you may end up with a big bunch of code where parts are not evolving at the same speed (ie: user interface will change oftently, but do the Api will change every time a UI fix is need. NO. And do every changes to the API will impact the UI. No.)

All code together enables shortcuts

What I mean by that, is that if everything is package together, a developer could be tempted to call some method directly instead of calling the API that should be the only valid facade. Any shortcut taken can lead will lead to code duplication, bugs, validation error, etc. Again: do not package your MVC app with your API.

Solutions

Use a Javascript framework

The other suggestions are good. AngularJS, ReactJS, EmberJS are good frameworks. (There are other, pick the one that fits your needs) But again, it will be a good choice for your architecture because you will create a clear separation between your UI app and your API app which are separated concerns. Your business logic will be well protected, and you will be sure that your code is only call via HTTP calls, the only valid facade of your API. In other words, you make sure nobody will take shortcuts.

Use .NET MVC app in its own project

If you still want to use .NET MVC, I would suggest that you call your API via HTTP: no shortcuts. I would create a different solution and with a separated MVC project where calls to the API would be made using the HttpClient or something like RestSharp . What you want here is to avoid to bind your UI to your API code. You want to bind your UI to the contract define by the API facade (api controllers) not their implementation.

Answer 3

I think better, of course if it possible in your situation, to use one of the JavaScript MVC frameworks. I think AngularJS, ReactJS or EmberJS will be the most coolest variants for your purpose. I don't think that calling ASP.MVC actions and then do another call to WEB API from there it's good idea, imho.