I want to build a Single Page Application using AngularJS as an client side framework but I struggle to understand if I can use the ASP.NET as my server side framework?
I know that AngularJS is an MVC framework and when I'm trying to decide wich server side framework to chose all I hear or read is MVC, MVC,...,MVC.
I know, this an subjective question, but still, can any one tell me if I need to learn ASP.NET MVC or I can still reach the desired result using the ASP.NET framework?
You can use whatever technology you want.
Basically to be able to communicate with angular you need something that listen for http requests (an http server so), parse them and that can send/read json (with maybe some extra libraries). The static pages can just be deserves by an apache in front.
You could do that in C parsing the whole thing yourself, but for performance, maintenability, speed of development and a bunch of other reasons, it's better to use an appropriate framework.
If your application is not big-scaled, specially in the backend part just search for a c# rest framework that handle thing that url mapping and json.
Related
I have worked in ASP.NET CORE MVC, before.
What are all the advantages in using ReactJS over ASP.NET CORE?
Would not that additional library & its components, slow down the page
load, comparing plain Razor Views?
I tried web search, I am unable to get proper answers.
If you have independent apps in PC,Phones tablet,etc,you could just use React and core web api which is front-end and back-end separation.
By using Angular/React with api in server side:
1.You eliminate process of generating HTML in server side and you save CPU.
2.API produces small payload (json) and Razor (html) would be much larger in size, constant full page reloads and postback round trip. so API and SPA save bandwidth.
3.API and SPA could have different versioning, scaling and deployment scenarios.
4.By using API you can support mobile app too and if you start by Razor you may need api in future.
Below are some opinions on using Angular/React or razor:
1.Razor supports mobile,and both are optimized and fast in their own way. Razor optimizes code by not using a tree like MVC does. React is client side so it doesn't really use a tree, but also optimizes data in the HTML to an extent.
2.Angular (or React) is far superior in terms of performance.The model-binding aspects of Angular is a gigantic advantage of server-side rendering. Using Razor(or server side rendering in general) does, however, lend itself to better overall integrity as far as data goes and it makes for a better transition of data from front-end to back-end.
See ASP.NET Core 2.0 Razor vs Angular/React/etc
What are all the advantages in using ReactJS over ASP.NET CORE?
ReactJS is high performance and rapid development client side framework, you can use it throw asp.net core or any other server side framework to handle client side operations.
Would not that additional library & its components, slow down the page
load, comparing plain Razor Views?
ReactJS designed to be a single page application, and this kind of apps is more faster than multiple page applications, also ReactJS processing the DOM in different and smarter way.
If you want to use ReactJS in asp.net core you must keep in mind that asp.net core is the api part just to return the data (json or xml) or to receive your ajax request to post data.
All clients side parts will handled by ReactJS, no razor views, you can have only one to reference your reacts application or simply you can reference it using plain html page.
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...
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).
Or is Rails by itself just good for developing APIs?
It seems that ASP.NET Web API project types have some history intertwined with WCF (as is detailed in this post for example), so maybe it's not applicable to Rails.
UPDATE
To clarify, Microsoft has the ASP.NET MVC framework. Recently, they came out with a framework called ASP.NET Web API. ASP.NET Web API seems to have similarities to ASP.NET MVC, but is specialized and trimmed down for RESTful web services. Is there an equivalent in the Ruby/Rails space?
So, the answer is Yes to both questions. Rails does have an equivalent and its Rails.
ASP.NET Web API looks like at it's heart is just a RESTful router with type negotiation. I could be totally off base here, but from the tutorials I saw that's what it looked like to me.
So yes, from what I can tell, Rails supports most of the things that the Web API was created for. In fact in Rails most of this stuff is forced onto you until you become informed enough to be able to change it (assuming by that point you know better than to actually do that).
But, as far as Web API functionality. That really comes from the ability to support HTTP verbs (GET, POST, PUT, DELETE) which Rails does.
But a source of confusion might be that in Rails the RESTful API is actually the application itself. Meaning you don't need to implement any other libraries, it's just built that way.
Here's a quick example of that I mean
When you hit /users/1 you will get the data associated with that user depending on the format you requested. So if you request JSON the controller returns JSON, HTML you get HTML, XML you get XML, etc. (As long as said format is implemented for that resource)
A good overview of what I'm talking about are in these two sections:
Rails Guides::Controller: Rendering xml and json data
Rails Guides::Routing: Resources on the Web
So you could build a website, API, or both in a Rails app and they would all start the same way.
But from my limited knowledge on the matter, I would say a ASP.NET MVC with ASP.NET Web API program is actually a lot more like a Rails Program than the regular ASP.NET MVC programs that came before them.
Or it's all just a clever ploy to get as many Capital Letters in a title as humanly possible.
Take a look at grape. It is a pure "Rest" HTTP API framework in ruby.
WSO2 looks like a generic web services framework (as opposed to MVC like Rails) I can't vouch for it but it seems to be more a service framework in the style of WCF Web API (service in the generic sense, not just SOAP).
It's difficult to know what you mean by "APIs"... Rails and ASP are used for developing web sites, and WCF is essentially a web service platform. ASP and WCF have little in common, it's just normal for ASP applications to consume WCF services because they all run on the same stack and platform.
I suppose Rails on the Microsoft side would be a combination of ASP.NET MVC, Linq2SQL or EntityFramework and some WCF.
Ok, this isn't a direct answer to your question, however there seems to be some confusion... Microsoft's ASP.NET Web API is specifically a product offering with ASP.NET MVC 4+. It is a RESTful framework. How does it compare to RoR? I don't know having never tried to install RoR on Windows. As with anything else, experiences vary... Requirements vary. Also try to think ourside the language, construct, context, and framework. Is it better for developing API's? If you're using Linux/Unix, the answer is probably a yes. If you're on a Windows server, the question is a bit trickier.
Finally,
Writing in the ASP.NET Web API will have 0% to do with WCF. Perhaps it is implemented as such under the covers, but the ASP.NET Web API is (from what I've seen and done with it) strictly an HTTP bound API, not TCP/Binary/Piped/etc... like WCF. If you're ask
Yes. It's called Grails. It uses spring. There are tons of plugins available for it and it make creating webapps a breeze. Read more about it here.