I'm working on a project where we're going to create a SPA that have to be composed of many modules.
The idea is that the application will have modules like:
Dashboard
Orders
Customers
Financial
Others...
The idea is that any module can be a separated SPA, that will be consolidated by a MAIN APP, that will have the menu and will control the navigation between modules.
Based on that, we're plannig to struct our VS solution like these:
-- Solution
/ModuleA
/FrontEnd (single page application)
/ModuleB
/FrontEnd (single page application)
/Main
/Front (web project that will consolidated others)
As backend we'll use WEB.API (.net 4.5)
Our doubt is about what frameworks we have to use in these SPA (the actual plan is to use knockout.js, but we don't know if is the best choise) and how we can make this MAIN APP join the others modules dynamically.
Knockout is good for more simple usages. It does not support SPA and modular approach. So you would have to handle it by yourself (or with help of some extensions).
I recommend you to take a look at frameworks that support SPA out-of-the-box. My favorite is Angular, developed by Google.
It has great templating engine, supports IoC, routing, modules. You could easily make partial templates for your modules, put them into a separate files.
there are three key fact to build a SPA appliction.
client side routing
2-way-binding
client side template
knockout it self only take care of 2-way-binding, it's easy to use and powerful, but it need a lot of friend, for example sammyjs for routing, handlebar for client side template
and when you want to make main app to interact other moudles dynamically, it become difficute to use knockout.
so my recommandation is angularjs, it's really powerful, and it take care of everything, it's worth to spend a little to have a look at
If you want to continue using Knockout then have a look at Durandaljs which is a SPA framework. I have found it very easy to get up and running.
Related
Client side complexity will increase by adding angular mechanisms such as client side modules, controllers and models!
in the other hand by developing MVC .Net web applications we have a good pattern so supports a lot of features and specially increasing re-useability, which we generally miss that in angular based web applications
angular pages with MVC apps causes duplicate codes in server side and client side. i don't know any way to avoid duplicate models and also strongly-typed models!
ok, i know implementing strongly typed model mechanism which models comes from server side is hard. but at least i want to prevent duplicate code with some existing techniques or NEW techniques!
First: are there existing approach? i did not find after lots of searching.
Scenario:
I'm developing a Plugin-Based MVC application which has core and some plugins that they have been implemented on MVC atchitecture. so all of them have own controllers and also own actions and views. The starting page or the so called "Main Application" which starts at first of core staring and contains my plugins contents within, is a SPA(Single Page Application) application that is based on angular libraries.
Now you consider that we're going to have implement all of the our plugin views just in Main SPA application! for example every view in plugins maybe have some forms, models or inputs ... . but anything within there should be angular-based! and it increase client side complexity. in the other hands implementing some rules and helpers for plugins developers seems necessary to preventing irregularity.
my solution is customizing the WebViewPage and enrich it to have lots of helpers to provide angular elements and manage them. for example adding Angular helper which have own BeginForm method instead of Html.BeginForm, and it configures some attributed such as ng-submit and so on.
Second : Is there any better approach or existing better techniques to do it?
I want to create a largish ASP.NET MVC Web application. On some pages I would like to utilise AngularJS.
This app will not be a SPA.
At what point does this become a problem? For example at what point does running effectively two MVC paradigms become a headache?
Or is it a case of as long as you have clear delineation between what's using ASP.NET MVC (standard action methods etc) and what's using Angular JS then the two run side by side ok without giving you massive code organisation/maintainability headaches?
Cheers for any wisdom.
I'd love John Papas opinion!
Andrew
Since you are only asking for opinions, I will be happy to share my experience. The two do mix very well, and I think in most cases (at least most of my own development) the .NET side becomes very light weight.
Your .NET Web API Controller becomes a simple call to the Data Layer to populate a model or List(Of T) models. This gets returned as JSON to the Angular service.
From there, Angular takes over all of the logic until you need to perform another CRUD operation. Manipulating, validating, etc. all happens client-side in either the model (for me the Angular service acts as the model in MVVM) or the angular controller (which is really a ViewModel).
It's best if you let your model (Angular service) handle as much business logic as possible and restrict the Angular controller to responding to clicks, input controls, etc.
To sum up, let your .NET server side be very light. Just transport data back and forth to the Data Layer. Let Angular do the heavy lifting. You definitely do not need to be building a SPA to see the wonderful benefits of a JS data binding library, of which Angular is arguably the best of breed.
An excellent blog post that contains [ details of what I've discussed here ].
Good luck!
I use ASP.NET MVC alongside AngularJS for a fairly large in-house application. We don't really use many features of ASP.NET MVC beyond the basic page template and script bundling - so everything from the client-side is controlled by AngularJS and client-side routing - except for some distinctions we've made between 'modules' of the app where we wanted a different ng-app for each, along with different script dependencies.
If you're looking to take advantage of AngularJS on a page-by-page basis then I think you have no problem at all. As long as you reference the scripts (both core AngularJS scripts, and your AngularJS scripts for modules, controllers, etc.) correctly then you can just begin decorating elements with ng-app, ng-controller, etc. and it will just work. You could insert the relevant AngularJS scripts for relevant .cshtml pages using a #section declaration.
It will only be more complicated if you need a mix of server-side and client-side routing. Then it will be a case of carefully constructing ASP.NET MVC routes to deliver the SPA functionality where needed.
I see this term Full-Stack Framework, when dealing with Web Application Framework, but there seems to be different opinions on it, and would therefore like to hear your opinions.
I've read this thread on stackoverflow (What is Full stack mvc framework? How Grails is full stack framework?) but, it doesn't clarify the UI part enough?
In the Laravelbook (http://laravelbook.com/laravel-architecture/) it says:
"Laravel is referred to as a “full stack” framework because it handles everything from web serving to database management right down to HTML generation."
So by this definition ASP.NET MVC would also be a Full-Stack Framework?
But just because you can serve an end user with HTML, does it then make it a Full-Stack? What about the interaction (JavaScript)? Like this article says, http://www.smashingmagazine.com/2013/11/21/introduction-to-full-stack-javascript/
MEAN is also referred to as Full-Stack Framework and has AngularJS included for the user-interaction? I've read that this makes MEAN truly a Full-Stack Framework, and if Laravel or ASP.NET MVC is combined with lets say AngularJS, then these would be a Full-Stack Web Application Framework.
And this is where i get confused, because with Laravel or ASP.NET MVC you can build an application alone with the framework it self, and also ASP.NET have async operations build-in with controllers, so maybe would't need something like Angular?
Isn't the JS interactions like the ones you can do with Angular just a matter of opinion, and what about just using plain old jQuery library for the DOM updates? Does the Full-Stack need to have a JS framework?
How do you define or argument for something being a Full-Stack Web Application Framework?
A full-stack framework is able to handle everything you need to build a complete web application. It is not saying that you can't add anything else to it that might make it easier for you to achieve certain goals such as using Laravel for the back-end and AngularJS for the front-end.
Framework combining rises out of wanting to find the best possible solution for what you are trying to achieve. In the example mentioned above, developers find it beneficial to let AngularJS handle the front-end not only because it might make it easier to create a dynamic single page application, but also to achieve code separation between the front-end and back-end. This allows your application to be more modular, which we all know has a lot of benefits (testing, api creation, third party integration, etc).
In the end, it all depends on what you are trying to achieve. If your goal is to have a simple web application you might only need to have one full-stack framework, but if your application has multiple ambitions then you might find that combining frameworks would be the best possible solution.
I come from using ASP.NET MVC/Web API and now I am starting to use Angular but I am not clear on the proper way to mix them.
Once I am using Angular does the MVC sever side concepts still provide any value ? Or should I strictly be using Web API purely to get data for the angular HTTP calls ?
Any tips you have for a ASP.NET MVC guy transitioning to Angular would be helpful
Pure Web API
I used to be pretty hardcore with ASP.NET MVC but since I've met Angular I do not see one reason why I would use any server side content generation framework. Pure Angular/REST(WebApi) gives a richer and smoother result. It's much faster and allows you to build websites that come quite close to desktop applications, without any funky hacks.
Angular does have a little learning curve, but once your team has mastered it, you'll build much better websites in less time. Mainly this has to do with the fact that you don't have all these state(less) issues anymore.
For example imagine a wizard form with any traditional server side framework. Each page needs to be validated and submitted separately. Maybe the content of the page is dependent on values from a previous page. Maybe the user pressed the back button and is re-submitting an previous form. Where do we store the state of the client? All these complications do not exist when using Angular and REST.
So ... come over to the dark side ... we've got cookies.
Similar question
AngularJS is more associated with the single page application paradigm, and as such, doesn't benefit much from server-side technologies that render markup. There is no technical reason that precludes you using them together, but in a practical sense, why would you?
An SPA retrieves the assets it needs (JS, CSS, and HTML views) and runs on its own, communicating back to services to send or retrieve data. So, a server-side technology is still necessary for providing those services (as well as other means such as authentication and the likes), but the rendering parts are largely irrelevant and not particularly useful because it's a duplication of efforts, except MVC does it on the server side and Angular does it on the client. If you're using Angular, you want it on the client for best results. You can make Angular post HTML forms and retrieve partial views from MVC actions, but you'd be missing out on the best and easiest features of Angular and making your life harder.
MVC is pretty flexible and you could use it to service calls from an SPA application. However, WebAPI is more finely tuned and a bit easier to use for such services.
I've written a number of AngularJS applications, including a couple that migrated from pre-existing WebForms and MVC applications, and the ASP.NET aspect evolves towards a platform for delivering the AngularJS app as the actual client, and for hosting the application layer the client communicates to via REST (using WebAPI). MVC is a fine framework, but it usually finds itself without a job in these sorts of applications.
The ASP.NET application becomes another layer to the infrastructure, where its responsibilities are limited to:
Host the dependency container.
Wire the business logic implementations into the container.
Set up asset bundles for JS and CSS.
Host WebAPI services.
Enforce security, perform logging and diagnostics.
Interfacing with application caches for performance.
Another great thing about an SPA is it can increase bandwidth of your team. One group can blast out the services while the other lays in the client app. Since you can easily stub or mock REST services, you could have a fully working client app on mock services and swap out for the real ones when they're done.
You do have to invest up front on Angular, but it pays off big. Since you are already familiar with MVC, you have a leg-up on some of the core concepts.
It depends on the project you are working on.
If angularJS is something new for you I would rather pick a small low risk/pressure project to get started and ensure you learn how to do things in the right way (I have seen many projects using Angularjs wrong because of pressure, deadlines... lack of time to learn it in a proper way, e.g. using JQuery or accesing the DOM inside the controllers, etc...).
If the project is a green field one, and you have got some experience on AngularJS, it makes sense to abandon ASP.net MVC and in the server side go for pure REST/WebAPI.
If it's an existing project, you can pick up a complex subset of functionality and build that page as a separate angularJS app (e.g. your app is composed of a big bunch of standard simple / medium complexity Razor based pages but you need and advanced editor / page, that could be the target piece to build with AngularJS).
You can use Angular framework for front end development i.e to construct views. It provides you a robust architecture and once you learn you will find it's advantages over Asp.net MVC's razor view engine. To fetch data you have to use WebAPIs and now ASP.Net MVC project support both WebAPI and MVC controllers out of the box. You can refer below link start with Angular and ASP.Net MVC application development.
http://hive.rinoy.in/angular4-and-asp-net-mvc-hybrid-application/
There are two frameworks currently available for developing UI components for angular applications. I have used both these frameworks in one of the angular projects that I worked.
Material
https://material.angular.io/
PrimeNG
https://www.primefaces.org/primeng/#/
I started in the web development world with PHP, and then Rails in the recent few years. Since then I've been doing all my web projects in Rails.
Recently there seems to be a movement towards making Rails as a pure RESTful backend service and using frontend framework such as Backbone.js for all frontend interaction. I'm wondering what's you guys' take on it? Will this be the eventual future?
As well, besides Backbone.js, what are some other alternatives for frontend framework for this purpose?
Also assuming that I will want to support both a desktop version and a mobile version of my app, would this be a proper route to take? So I'll have a single backend service with different frontend services? This way I don't need to manage all the views on Rails' side?
Thanks!
For Client-side frameworks, this article has a list of 20 of them with pro's and con's:
http://net.tutsplus.com/articles/web-roundups/20-javascript-frameworks-worth-checking-out/
Here's the list:
Backbone.js
Knockout.js
Asana luna
Cappucino
Sproutcore
BatmanJS
corMVC
TrimJunction
pureMVC
jamal
choco
sammyjs
extJS
agilityJS
eyeballs
activejs
spinejs
qooxdoo
These are roughly all about creating client-side, ajax-based, javascript MVC frameworks.
If you're looking to start somewhere, then I recommend thinking about Client-Side Templates (...ates...ates...ates) (just the "V") to support a service-oriented architecture (many clients are supported by service-endpoints you create).
It's a new technique that involves modularizing your client-side code, bringing MVC to the client, and let business-logic live in the platform. A lot of Software-as-a-Service applications are leveraging them, and with the increasing sophisticated of javascript libraries and frameworks, as well as browser capabilities with HTML5, CSS3, etc. there's going to be an increasing sophistication in client-side presentation.
So learn it.
What are the benefits?
To paraphrase Linked In: for leveraging browser-caching, de-coupling your front-end client-side presentation, asynchronous load, progressive rendering (for some frameworks), performance, ajax-interaction, and more.
Several great frameworks include:
mustache
dust.js
handlebars
Google Closure Templates
Nun
Mu
kite
I highly recommend looking at Linked In's move away from JSP towards Client-Side Templates and why they choose dust.js in Linked In's front-end client-side templates throwdown for a comparison. They go into much greater detail, and research, as to why they changed their stack to support this (it involved using 3 server-side technologies), as well as their comparisons of all the frameworks they could find.
I did something like this a few years ago in .net. Is was not via proper .NET MVC and didn't use the new JS frameworks, but the principle was the same; server code returns JSON to javascript which builds the page and interactions etc.
The result was a lovely responsive website, but, maintenance was a nightmare. Be very careful to keep your JS code well organised.
Personally, I find it easier to maintain server code (in any language) than javascript so I wouldn't go down that route again.
(IMHO)
Fran
It is my opinion that contemporary web applications are moving towards this model of having RESTful back-end and all the view interactions coded in front-end. These free video tutorials from Joe Zim:
http://www.joezimjs.com/javascript/introduction-to-backbone-js-part-1-models-video-tutorial/
helped me understand backbone and how it can simplify templating and view renders.