I've explored the ASP.net web API framework and MVC 4. I understand the point of using web API that only return data then in client side we use javascript, ajax to handle all actions via HTTP verbs. On the other hand, MVC controller can return data and view we can handle event via [HttpPost] in controller.
I saw some people they make 2 projects in a solution: one is Web API in MVC 4 and the other is MVC 4 Internet Application. Is it a good idea? I didnt see the relation between two kind of projects. Can anyone explain me the how two project can communicate with each other, and what is the advantage and disadvantage of that way?
Note: in this solution he/she still uses Httppost to handle event and use MVC controller return view with Model binding.
Well I guess this is going to be a pragmatic conversation...
For starters, it seems like the Asp.net WebApi and Asp.net MVC are going to be aligned in Asp.Net V-Next, so there is going to be One base controller class that will return what ever datatype you wish (ActionResult, Json etc).
And from the recent years experience I think the trend is to have a WebApi that exposes data and a portal(client) that is just a JS web application with no C# code that just calls the Api from the browser and does what it needs to do.
So that way we basically save one hup to the server(the MVC server) and we can directly call the API from the browser.
However some people would still argue about load balancing, scaling, caching etc that you could have if you keep the MVC tier there but still all those things could be done in the WebApi and JS application too...
So long story short, I think if you want to move with the trend I think you should go with a RESTful API and have your client to call it from the browser directly with JavaScript...
Related
Cenario
Website: ASP.Net MVC 5 managing models, controllers and views.
Api: RESTful Web api managing models, controllers and returning JSON
The problem: Code duplication in BL. We are always redoing the same logic in both places.
The approach I have in mind:
Take the BL out of the Website MVC and keep it only in Web Api in a separated VS solution
The Website now is a consumer of Web Api
About the content negotiation, I think in two options:
Web Api "knows" which format to return (ViewResult, JSON or XML) and serialize/deserialize in BL depending of who is requesting (website, mobile apps, etc.). The advantage I see is to keep taking
advantage of strongly typed model to render a view in Website
Web Api always return JSON and the consumer app handle result in client
Questions:
Is this approach a good practise?
Which is better: Web Api always returning JSON or a smart Web Api who "knows" which format to return?
Like #David said, you don't really need to consume web services in your MVC controllers. You could just design it in such a way that your MVC and API layers are just another "view" to your Business layer. So, in case you are thinking in a terms of your visual studio solution, your might have a Data layer project, a Business layer project and 2 front end projects MVC and API.
I am currently starting a massive web app project, and one of the requirements is that down the line I may be required to allow an iOS and Android app to interface with my application, I figured the best solution was to create a RESTful API and have the web application interface with it. However, my coworker who does front end development is unfamiliar with using a javascript framework such as backbone.js (more of a library I know), ember.js or angular.js. Since we're using asp.net I figured that the I could handle authentication and routing using asp.net MVC, delivering seperate views depending on the route, and he can handle the data manipulation only, However, I can't seem to figure out how to seperate routing from the javascript framework, I've looked into ember.js and backbone and both of them seem to require routing to be handled on their end for it to really work.
Does anyone have any idea how to implement data manipulation without the need for routing?
What you are describing is generally called API oriented architecture, meaning you have a RESTful service on a back-end and rich client-side application on front end.
The point is, it basically does not matter what technology you pick up on server. It could be anything: ASP.NET MVC, Web API, Express.js or Django. As soon as it's really RESTful and pure. By purity I mean, it deals only with data, no serving of HTML or something.
Server just specify the interface you work with data,
GET /invoices // get all invoices
GET /invoices/:id // get invoice by id
POST /invoices // post new invoice
If you confident with .NET, WebAPI is probably good choice. Typically you would prefer JSON output, WebAPI could handle content negotiation for you.
Now, the client job is to consume the API data and dynamically create HTML in browser. A lot of options now: Backbone.js, Angular.js etc.
Please be aware: client side routing and server side routing are completely different things.
Server side routing: routes particular HTTP request to particular controllers action (or any function).
Client side routing: detects the URL change and triggers corresponding JavaScript function to handle change. Client side routing is vital for SPA (single page applications). You can find a bit more information on SPA on that blog post.
Have a look at KnockoutJS, which would allow you to use ASP.NET MVC for routing or another JavaScript library like sammy.js (just for routing) or Durandal (for routing and navigation).
Note: Durandal version 1 used sammy.js internally, but version 2 has a custom routing engine and no longer uses sammy.js.
I wish to implement REST service which will be integrated with ASP site (basically the same project).
I've tried to provide my custom VirtualPathProvider (VPP) and it works, but to a certain degree. First, the content-type of the response is always application/octet-stream. Second, only GET requests are piped through the VPP. I've seen people playing around with HttpApplication to solve these problems. I am not sure if I wish to follow the path of hacking the ASP as it might take a lot of time, and in the end it might be simply impossible to accomplish the task.
Is there a way to do it, or I should create a separate page for MVC, and talk with it via some inter-process communication. This way MVC will be handle the REST requests and call my code in response. And vice versa - ASP will be able to send REST requests to remote servers.
If there are any other, cleaner, safer & easier, ways of linking MVC with vanilla ASP, then feel free to post them in comments/answers.
VirtualPathProvider is meant to be a way to virtualize the filesystem for internal ASP.NET operations (e.g. storing *.aspx and *.master files in a database), it is only coincidental that it works for user-provided URIs and requests.
Your best bet is just to use ASP.NET MVC, which is now integrated with ASP.NET (since 4.x) or as an easily redistributable component in .NET 3.x. ASP.NET MVC does play nice with WinForms in the same application, so don't reinvent the wheel.
However, if you are insistent, the only real option is to do it all from within a custom IHttpHandler that chooses to handle incoming requests or not (as you won't have ASP.NET URL Routing because you're not using ASP.NET MVC).
I have an existing Asp.Net MVC Website and I would also like to provide a Web Service from the same domain.
What is the best way to approach creating a web service in this scenerio?
Do I add to this project or...?
You should be able to add an WebService file directly to the MVC project.
Right click on solution and select add new item, then select the web category and att the bottom of the list there should be Web Service.
Just remember to check that the routes does not eat up the call to the webservice.
That way the webservice can get access to the same model classes as the MVC application.
You can add a web service to the project just as you do in regular ASP.NET web apps, however, MVC basically IS a web service. You could create a controller that handles all the requests that you want your web service to handle.
With the advent of MVC it is quite common to do applications that only ever load a view once, then use AJAX and client scripting almost the entire rest of the life of the application. Your AJAX calls just hit up action methods for their goods and then use the deliciousness that is JSON to parse the data and utilize it.
In my opinion designing a web service as a controller instead of using [WebMethods] is far simpler and a lot more fun!
First, the question is "what do we mean by web service?" This can mean anything from a MVC page that responds using XML, JSON or some other agreed upon format to full blown SOAP and WS-* encumbered nightmares.
Anyhow, perhaps the best place to start is the WCF restful services -- these play very nicely with MVC, including routing.
The cool kids are using openrasta.
I have just experimented my first ajax enabled WCF service in a sample asp.net webform application... If i have 10-15 pages in my webapplication which involves add,edit,view and delete operations, is it possible to make them ajax post and get without using .cs(codebehind) of all pages...
What are the pros and cons when choosing ajax enabled WCF service in an asp.net webform application?
At first, if you want to implement the server side of jQuery Ajax calls, you can do this with either ASMX or WCF services. You can find a short comparison between these two here. WCF is more modern technology and will be my preferred choice for new projects. It can provide you with the following:
Help you program against an interface
It will serialize/deserialize objects to JSON for you. No need for JSON libraries
Provides client methods that you can use (via the ScriptManager). It is also easy to use jQuery if you prefer
As an disadvantage I would say that it will take you some time to learn the technology. I found that proper configuration of web.config was a little tricky.
I usually have a single svc service that serves all Ajax requests. You can implement as many methods as you want in a single service. The services are called from different pages.