I have a newbie question. If we use React (or any other similar framework) in ASP.NET MVC we end up with very simple (single?) cshtml file which delegates UI rendering to React. So in that case, why bother with MVC? Shouldn't be a better idea to create WebAPI REST service, and a frontend client application in pure JavaScript/React as two completely separated applications?
I just don't get the idea of using ASP.NET MVC in combination with different frontend frameworks...
So basically you're correct in that you would not use a typical MVC setup when using something like React or Angular. That said with the newer versions of ASP.NET there is no difference between an API controller and an MVC controller. You'd write your API endpoints in this new unified controller and use it like a standard RESTful API for your React application to hit. You can keep both in the same solution and serve up the index.html to start your web application.
In my experience it is better to just separate the two entirely and built a .Net back end in one VS solution and then use something like WebStorm to write your web application in another.
Compared to pmanderson54's answer, he is right about separating .NET back end and React Front end apps.
Just don't forget to configure enabling Cross-origin Requests in Web Api
https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/enabling-cross-origin-requests-in-web-api
Related
I would like to build a new web site using AngularJS. The idea is to build a server side API with Ruby on Rails that serve Json to a front-end AngularJS.
My question is: Is it better to create a full AngluarJS front-end or a standard ruby on rails front-end with some Angular ?
I know Angular can handle routing so a full application is possible but it looks like the default behavior is for single page app.
For example I wonder if it's not a problem to make some change in an angular page 1 that should modify a page 2. This page 2 will not be updated until an action is taken on the page or the user reload the page.
Is there something wrong in my approach ? What do you advise ?
Thanks for reading.
I have personally done variations of a number of angular apps, varying from SPA with 50K+ views to simply using angular as an extension of basic javascript for useful testing and modularization.
The answer to your question isn't actually all that technical but more has to do with the nature of your application and team (You're essentially trying to pick what type of screwdriver to use). As what you're trying to do is feasible on both the client and server side.
Important questions to ask:
Is your team more comfortable in Rails or Angular
How dynamic are your web pages expected to be
What browsers are you supporting
Is there a requirement for data latency and communication with the server
Are you also going to be reusing the server API for other applications
These questions will drive you towards use of Angular or Rails or the combination of the technologies to find the balance.
The routing mechanism in angular is only within a single window object.
If you have two windows you will have two angular applications. If you want to communicate between the windows object angular does not provide any special mechanism further than standard HTML and javascript.
I don't know what is the better approach for you, that depends in your business requirements and constraints.
I'm developing a SPA application and I can't decide, whether to use server-side MVC framework or not.
I have chosen AngularJS as the client-side framework. I was thinking I could use Symfony 2 on the server side, but I also considered using pure OOP oriented PHP. Something like this - database class, model classes (User, UserDbManager, ...). I would use something like Slim to create the REST API.
It seems counterproductive to basically write the same code twice, once on the client side and once on the server side, if I could just use the server to serve the data from the database.
If anyone had done similar decision, I'd be happy, if you'd share your thoughts and tips about it.
I would decide depending on the complexity of the requirement.
If it's a very simple I don't see a huge difference in using a framework or plain old php.
But if it's a complex project, I would definitely go with a framework considering the fact that most of the core functions one might need are already there and quicker development.
Again, it would come down to personal preference too.
Codeigniter has been said easy to learn for beginners in framework.
Symfony and zend are more commercially used (I am not saying others are not, but I see more vacancies asking for symfony or zend development experience).
My suggestion will be if you are having angular js as clientside framework. Then take advantage of it and use some api on server side to just return some json kind of response. Why send html on network when you have angular js on clientside to work with dom. just send data from server to client.
I have also done same. I have jquery for clientside and i am using spring mvc to send response as json.
We have a project using ASP.NET MVC 4 and it is a multi page mvc web app. We are planning to use Backbone js as the front end javascript framework . What is the best practice or suggestion to organize the backbone js code for the multi page mvc web app?
How it will be organized if we use Knockout js instead of backbone js.?
Thanks,
Sarathy
In my experience, Backbone is best used for SPA's (Single page apps). It is designed to help bring structure to javascript heavy applications. You first need to tell us why you are looking to use either of these libraries and a description of the site or app you are building? Are you using MVC 4 Web API, because Backbone connects to your existing API over a RESTful JSON interface and Web API is a perfect fit for this.
The only reason I would see to use Backbone for a multi-page mvc web app, is if you are looking for the app to function with javascript disabled and progressively enhance the app with Backbone. If you are looking to use pushstate, then you would also need to serve the individual pages.
I think the best bet is to look at TODOMVC to get a feel of the different libraries. Look how they work and see which, if any, would be a good fit for your app.
We use MVC2 to build up our web app. There are some complicated pages in our project. They have plenty of user interactivities, realtime stock data and charts, requiring no page refresh.
I am new to front end development and ASP.NET MVC2. After using it for a while I think it's a form-based framework for presentation layer(I maybe wrong). If most UI actions are excuted inside one web page, using ajax and javascript to render data and run UI logic seems better.
Then I find there're two way to rendering UI in our app: binding UI model to View using MVC2 and filling the view using javascript. This seems not so elegant or may possibly mess if more and more views are implemented.
It seems MVC2 controller is good at being RESTful UI model data provider. So I think make the solution as Controller(model data)->HTML layouts + javascript(ui logic) could be a good way to implement such a rich client web app. Is it a good practice to do? Or what's your advice on this kind of project? Are there any web resources(articles or sample projects) for reference?
Thanks a lot.
It's not a bad practice to make your actions return just data, you could make your actions return JSon objects since they are lightweight and use JSonP to make ajax request across different domains.
You can try the new template JQuery PlugIn to render your views.
My suggestion would be to build up your application such that it works without JavaScript. Then use JQuery (a JavaScript library) and Ajax to improve the user experience.
Be aware that it is entirely possible that your RIA needs go beyond what one can do with Jquery. In these scenarios one might consider another solution (HTML5, SilverLight, Flash, etc.). Or you could tone down your RIA needs.
I am developing a Java web services application that is (mostly) to be used by other SOA clients. Currently I am planning on using CXF to publish my various web services & methods using SOAP/XML.
I am now being asked to investigate a thin client web-application for this tool. I have been looking into Javascript libraries such as ExtJS and Dojo -- and they seem really straightforward. Given that this is a web application and not a web site, I really don't think I'll be creating very many static HTML pages -- maybe even just one. Mostly I plan on using an XMLHttpRequest object to hit the web services I already have and take the results and modify the DOM.
However, I have never created a browser-based UI before and in the context of a nearly 100% Javascript application I am trying to figure what role, if any, a server side MVC framwork such as Spring MVC will buy me. Is it needed for this? Whats it good for?
If you use the CXF JavaScript client generator and go for a single page JS application, I don't see what a Java MVC framework will give you (apart from extra complexity).
Spring MVC is a web-based module based on servlets and JSPs. If you're writing a JavaScript UI that calls on services directly, I'd say that you don't need Spring MVC.