I have asp.net mvc app written a couple of years ago and the more I add to it, I tend to make REST/AJAX calls to the controller to get data from it.
My question is do I carry on working in this way or should I expose the data as a separate REST services (WCF way of doing things)?
It feels that the boundary on what a mvc app is designed to do and the design of web service is getting blurred. The Mvc app (apart from separation) initially produced web pages, now it is being used to provide service based data.
JD
You should use Web API over ASP.Net MVC if you would want your controller to return data in multiple formats like, JSON, XML, etc. Also, specifying the data format in Web API is simple and easy to configure. Web API also scores over ASP.Net MVC in its ability to be self-hosted (similar to WCF).
Web API helps to build REST-ful services over the . NET Framework and it also supports content-negotiation(it's about deciding the best response format data that could be acceptable by the client. it could be JSON, XML, ATOM or other formatted data), self-hosting which are not in MVC.
ASP.NET MVC is no longer in active development.
Asp.Net Web Form has built-in data controls and best for rapid development with powerful data access. Asp.Net MVC is lightweight, provide full control over markup and support many features that allow fast & agile development. Hence it is best for developing an interactive web application with the latest web standards.
I see two possible scenarios
Single web app. In this case you carry on adding methods to the controller. This is good because it keeps relevant to the controller functionality in one place and will save you time. It is not suitable if the controller is being called from another web application. Simple, ugly but works, takes little time for development and much time for maintenance.
Web app + web service. You can segregate data retrieval methods into the service interface. The positive side is that you system becomes much more modular and independent, which is good for maintenance. If you predict that there will be other methods that will be added soon or if the methods are used by other web applications, then this path is probably better than extending the current web app. The negative side is that the new service will require some refactoring to the current web application and will take time to be developed/tested etc. This decision brings more complexity, but makes your application easy to be extended.
I think WCF has several advantages over MVC if you are strictly sending data, specifically in terms of data formats being unambiguous (SOAP vs. using home-brewed encodings), industry-wide tool support, excellent support for different types of bindings (i.e. not just HTTP), various transport level services, nice logging and tracing capabilities, etc.
In the end though, it boils down to: is there a significant enough advantage to going with WCF for your case. That is something that you'd have to figure out yourself.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With