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.
Related
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.
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/#/
Is there much point to using angular js on top of asp.net mvc since they're kind of both doing the same thing? What are the advantages to using angular over asp.net mvc + jquery? What kind of scenario would you pick angular in? If you do pick angular in a microsoft environment, what would you run on the server side? Would it be something like Web API? Or is there still benefit of using traditional asp.net mvc?
This question is a bit subjective, however here was our reasoning.
Let the client handle rendering of pages, free up resources on the server.
Leverage built in caching of cache servers since we are just dealing with <html/> content.
Since the pages are cached the only traffic back and forth is json payloads.
We have been using NancyFx, but WebAPI or Service Stack would work just fine.
We wanted to build a responsive single page application and AngularJs fit the bill for testability as full feature rich framework.
AngularJs forces you into a pattern that we needed for JavaScript, in the past our jQuery heavy applications turned into functional spaghetti (That was our fault but being guided by Angular helped out a lot).
As with all frameworks pick the one that suites your needs
On my site http://www.reviewstoshare.com, I am using AngularJS along with ASP.NET MVC. The main reason I did not go all the way with AngularJS was that SEO is not easily achieved with AngularJS.
Keep in mind that my site was already built using ASP.MVC + Jquery for in page interaction as needed.
On the other hand there is still some "Ajaxy" nature to the site like comments, voting, flagging etc. Not too different than Stackoverflow itself. Before AngularJS it was a mess of Jquery plugins and functions within $(document).ready() callback, not to mention the JS code was not testable much.
In the end, I went with both.
If you fancy using Java Script framework then Angular JS rocks.
SEO could be the issue. You need to have deeper understanding of DOM and Java Script as compared to other famous JS Frameworks.
I ve developed a Proof of Concept - using Angular JS with Require JS using ASP.net MVC
You can have a look at it at the below given link
http://angualrjsrequirejsaspmvc.blogspot.com/2013/08/angular-js-with-require-js-front-end.html
I am wondering what is the better way to go. I created a webapi project and am currently working on making my api.
In the future I want a full asp.net mvc 4 website and that could also contain forms to insert data into my database.
I am not sure if I should
a)
Make a new area in my web api project and build my website from there.
b)
Keep it in the same area and just make some new controllers and such in the web api project.
c) add a new asp.net mvc 4 project to my web api solution project.
Definitely two projects. In fact, I'd actually recommend three projects:
MVC website
Class library, for sharing your DAL/Service layers
Web API
Your MVC site shouldn't need to query your Web API, that's just going to create HTTP latency that's unnecessary. Both your MVC site and your Web API, are just "frontends" for your class library. They will both reference the class library and interact with the class library.
A Web API is only necessary if you're trying to provide third-party access or you're interfacing with a project in another language. If everything is .NET then just share the DLLs and call it a day.
K. Scott Allen recently wrote a brilliant post on the Coexistence of ASP.NET MVC and WebAPI it covers the most common scenarios and when it's appropriate to use WebAPI with MVC or when you should just use MVC.
I would use that as your guide pick the solution that best meets your current needs. My advice is to keep it simple and if your requirements are simple then there is no reason not keep WebAPI and MVC in the same project - it works just fine. As your requirements change you can always split them up into different projects or solutions, but by then you will know exactly why you are doing so.
http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx
absolutely,
go through link http://efmvc.codeplex.com/
which is the best architecture to develop the big apps
may this one is help you...
another BEST one MVC N-Tier architecture
MVC ---------> WEB API (services)------ > here BL | DL(ORM) | DB)
which you create this in same solution and build the app...
Separate projects for the web api and the web interface will help split things up, but it does cause duplications. We went that way recently and it works well, but it caused a few problems.
Arguments for having a single project :
Since we don't have a domain name yet, we have our API on the 8080 port. We could use a directory binding to make the API accessible from a sub-directory of the web interface but we were worried about production only bugs about absolute path resolution.
Many settings are shared between the two projects so we have to copy them in both web.config files.
Arguments for having multiple projects :
They are easier to upgrade since they can have different dependencies and they can be built totally independently. For example, our API project uses a few more recent versions of some dependencies.
It forces you to extract all of your business logic into a separate library and makes it easier to think about both projects as separate sub-systems.
It is easier to setup the web interface to a separate machine if the load is too much. This is a concern for us, but that may not be your case.
If I had to make this decision again, I probably wouldn't bother with separate projects unless the system was extremely complex and I needed the additional structure. An argument can be made for both options, but I think the deployment headache it brings is not worth it.
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.