Looking at this question:
SO question
The accepted answer by Darin Dimitrov looks appealing (.NET 4.5 version). I am just wondering how this compares performance wise with client side solutions (e.g. using knockout/angular/jquery) to assemble the HTML given some JSON from the web api endpoint. Did someone ever do some perfromance tests on this. What are the pros and cons of the 'client side solution' vs the 'razor server side' solution?
You should have to define performance.
However there is a very big difference between the two options:
if you do it client-side (with ko/ng/jQuery) the server only executes the API controller action and returns the formatted data.
if you do it server side, apart from execution the API action, the server has to execute the MVC controller action, so, undoubtedly, the server does more work.
The only conclusion is that the server has less work to do in the first case. And, usually, the network traffic is reduced (a JSON object is usually lighter than a rendered partial view).
If we're speaking about the user experience, in general client side technologies (jQuery, ko, ng) offer a much better user experience becasue the page is much more responsive: it's easy to show/hide elements, set the focus, make trivial calculations, remote validations... And if we use modern libraries, we can go further on improving the interface resposiveness. For example breeze.js allows to cache data in the client side to avoid making extra ajax calls to the server, giving a much more responsive experience, specially if you anticipate what data can be needed and cached it before hand. You could even persist data in HTML5 storage, so that it's available for other sessions.
Then, from the user viewpoint, I think it's much better the second option. And the server has less work to do, which can make it also more resposive in high-traffic sites.
Even so, I don't know what is "more performant" or even what it is "to be performant".
Whatever it is, using client side technologies is a much better option. But it takes some time to master the associated technologies.
Related
I'm building a new SPA, and I'm having some problems dealing with what appear to be conflicting concerns.
So, on the surface, the SPA is fairly basic CRUD. However, there's a catch: They also want all of the functionality to be available as Web API.
That sounds like a fit, given that Breeze works on top of Web API, but I keep feeling that I'm pounding a square peg into a round hole. Can someone give me a tow?
Example of the issue:
Suppose I have a screen for creating/adding widgets.
There are some validations
There are some business rules (if the widget weighs over 5 lbs, call another web service that sends an email)
So, with Breeze, that's pretty easy. I just hook up my EFContext Provider, and hook the BeforeSaveEntity(ies) events and go to town.
This is great, but they want a CreateWidget web API. It's not going to be acceptable for the client to have to build a Breeze compatible JObject bundle to simulate the save.
The API would seem to want a conventional DTO/Domain Service sort of thing. Something like:
string CreateWidget(widgetDto)
Breeze's client side library is fantastic, and I want to be able to use it for my GUI app. However, I'm having a hard time figuring out how to use Breeze and still separate concerns on my server side so that the domain services are usable from an imperative API, and so that they will support unit testing.
(I know you can override SaveCore, and I've looked at the NoDb example, but the important part just says something like "// your code would go here". Every avenue that I try smells like a huge hack, because really, Breeze wants control of the whole vertical stack on the server, and I just want it to decode the breeze client posts back to my DTOs so that I can map to the same domain services that my API will use, and then I want to traffic errors raised by my services back to the client (which we surface with the really excellent wzValidate angular directive).
I have read a lot of posts of people saying that if you really feel that you need DTOs, then you can use them, but I have come up empty searching for a working example that also incorporates business logic on the server. Can someone point me to a good resource?
I need to ask you guys/gals out there about a concept of website development that I'm not finding a whole lot of documentation about. Maybe I'm using the wrong vocabulary? It's basicly rendering the views (in a MVC type sites) on the client side vs server side.
Here's what I know so far. Commonly in a Model, Controller, View type website, the view is what the HTML/CSS/Javascript design gets programmed to. Now the idea is that the server processes all the HTML/CSS/Javascript, and what gets sent to the client browser, is the finished view. I believe this applies to C#, MS.net, Java, PHP, as well as Rails.
Now, the way client-side works is, the server stops at trying to render views for HTML/CSS/Javascript, and instead only renders views for raw XML data. In addition, a Javascript like program (handlebars.js and mustache.js, eg) is downloaded once, cached, and the XML data is feed through the javascript program which in turn dynamically creates the HTML/CSS/Javascript view. The idea behind this is that only XML data, the initial JS program, and media are the only things needed from the server. Instead of refreshing the page each time, only XML or JSON data is needed.
Now, I can see an advantage for a small business that wishes to advertise, blogs, resellers, etc. 1. Minimize the amount of raw data that comes out of the company server, and 2. Send media and precompiled code to a cloud serving site like amazon.com.
But what if all information needs to be served from the company's servers? It seems to me that a number of arguments towards choosing client-side have already been addressed in Rails 3+
How can I find out more information about this so I can make a more knowledgeable decision as to choose client vs server?
All comments are welcome! Thanks (^_^)
Servers only touch PHP, Java, ASP.NET(C# and VB.NET), etc. JavaScript is a Client Side Code. the MVC Model is more for the Server side code on how you break it up. It tries to keep the logic away from the design. a good example of how this works would be Magento.
Also, client-side code is vulnerable to hackers
http://php-html.net/tutorials/model-view-controller-in-php/
I'm using .NET MVC for all my serverside logic and serving out initial pages, but my application is very heavy on the client-side so I have adopted Backbone.JS which is proving to be very useful.
I'm unsure how to architect my system to incorporate both technologies though. The way I see it I have two options
Scrap the 'V' from MVC on the server-side, return JSON Data to the
client on pageload and use backbone clientside templates to build up
the GUI from the base JSON/Backbone Models.
Return the initial pages from the server fully rendered in .NET MVC.
Also return the data that was used to render them and call the
collection.reset({silent: true}) method to link up the
returned data to the view. Am I right in thinking that this will
allow me to subsequently make changes to using the add/remove/change
handlers on the views?
1 Troubles me as I'm afraid of letting go of any part of server-side MVC, its where my core skill lies.
2 Troubles me as I'm concerned I might be introducing risk and work by having two different rendering methods on client server.
Whats the correct way to combine Server-side MVC with backbone.js 1 or 2 or some other way?
You are not really scrapping the V, you're just changing it's representation from HTML to JSON. You are troubled because you feel more comfortable with the server side stuff, and that's not really a valid concern... you'll get done what needs to be done, and learn/create the Javascript patterns as you go.
This is one way to do it, and it really helps if you need a javascript disabled fallback or you're bound by accessibility guidelines. The part you're missing is that you will have to re-render the page once it's loaded to attach your models up to the DOM elements. Alternatively you could use a tool that handles this mapping for you, but that's added complexity you'll have to weigh out yourself.
In the Careers usage of backbone, we are not bound to support javascript-less scenarios, and we so we just load the templates + js on the initial load, then let the router take over and use something more like your first idea. Since it sounds like you're just getting started, the biggest thing that helped us really get moving was realizing that it's way easier to make changes to your model and then let your views subscribe to model change events (instead of the other way around).
I don't know what the Accepted Way is, but I've found it problematic to combine V from the server side and then weaving Backbone (etc) in. In very controlled situations it can work out, but if your app is going to be extremely heavy on the client side, my suggestion would be to forget about rendering on the server side and just return JSON and let Backbone handle the rendering of your content through some sort of templating (Mustache, etc).
Yes, you have full control over the Backbone events, so you will have a handle on them to do what you wish.
I hear you about giving up part of your skill set on the server side. I was the same way but if this is what your project calls for, I think you'll find it easier to let the server side rendering go for this.
Good luck!
I was wondering this for quite a while and haven't really found an answer for this yet.
Why would you use Backbone.js exaclty inside a Rails application? Is it to extend functionality, have a more MVC pattern for your JS, build better API's...?
At the moment I can't see a reason why you would want to use it for something, because I don't think I understand the concept of Backbone.js
The big advantage of rails is that you have one platform and one language that you use that will handle the server-code and can generate the client-code (using the views).
Undoubtedly this theoretical advantage quickly starts slipping once you want to improve your user-experience with javascript and jquery. So actually you still have to learn two languages.
But still: all your models, business-rules, ... is handled on the server-side in Ruby. This also means that the server always has to be reachable.
What a javacript/client MVC (like Backbone.js, Sproutcore, ...) can offer you is a more native application feel. A single web-page application, like e.g. Gmail.
Depending on your requirements there are some very valid use-cases for such a platform. E.g. in places or devices with low connectivity it could be very useful (with HTML5) to have a web-application that does not need to be "online" all the time. It could save data and edits to the local storage and sync back to the server/database when the device is back online.
But, there is a big disadvantage when developing client MVC applications in combination with Rails: you will have to do some double development (it is the same when you are using flex/silverlight). Your models will need to be defined both on the server and on the client. I can imagine that some improvements could be made, like on the client MVC you are actually using presenter-classes, which on the server-side could be stored in different models/tables. But still there will be duplication of logic, models, ...
So that's why I think that for most applications, at the moment, it is not wise to switch to some client MVC framework. It will be a lot more work.
But when you do need the look and feel of a real native application, or a one-page-web application, then a javascript client MVC framework is the way to go. And if you do need a client MVC framework, I would propose Sproutcore.
To simply ajaxify your current rails application (reduces load-time of every single page), take a look at pjax-rails.
(better late than never - hope this is useful to someone)
The description on backbonejs's website seems like a lot of words thrown together without much meaning. There is a big hype around it but what's all the fuss about?
The premise behind backbone is that modern day, single page web apps (think gmail) quickly become a very complex interaction between syncing dom elements, UI events and the backend. You could easily find yourself storing data within the dom elements, and then having to somehow extract the data again to update the database. If you don't structure your code very carefully, you'll quickly end up with spaghetti code full of complex bindings, or code without backbone.
Using backbone's models, collections and views gives you a well thought out structure to work within, allowing you to build large apps without being overwhelmed by their complexity. What's more, it ties in beautifully with a restful backend.
I'm frustrated recently by all of the choices that Microsoft offers to develop a web form. There is Sharepoint, Infopath without Sharepoint, ASP.NET Web Forms (with different controls for each runtime), ASP.NET without Web Forms, ASP.NET MVC framework, Silverlight, and WCF. Rendering and databinding technologies aside, there are a handful of different ways to pass data to and from the database (DataSets, LINQ, SqlDataControls, and many more) And those are only the ones that I can name in a minute or so - I'm sure I'm missing some very old technologies (did FoxPro ever get a web front end) or very new things in the process of rolling out of Microsoft Labs.
If I want to move away from using ASP.NET Web Forms and DataSets, what's the best way to move right now for data driven forms? What have you worked with that delivered good value for your programming time? I'm tempted to try working with LINQ to Entities and the new MVC framework, but I don't know enough about all these new technologies to choose where the value lies.
It's been said many times before - there is no "what's best". If any of these tools were best, than the rest wouldn't exist. "Data driven forms" is a pretty broad requirements statement.
They all have advantages and disadvantages in other areas, but all of them are capable of "data driven forms". MVC is lower-level forms - you will have to put in all the HTML and form processing yourself, however, it is much closer to dealing directly with HTTP, so lots of people find it much lighter-weight and easier to work with.
Silverlight has drawbacks in that it uses a diminished set of the .Net libraries, and requires the users to install browser plugins.
WCF would provide the data behind your forms, and would be very suitable if you're planning on opening up a public API or consuming the data in other ways.
You may find it beneficial to research each technology for even an hour each, and you would have a better understanding of which might fit your needs.
If you're using ASP.NET (which, when trying to code a regular website, feels a little "shoehorned"), then I thoroughly recommend trying Microsoft's MVC framework. It's a real breath of fresh air!
From a value per working-hour POV, it really depends on what you're doing. I can't say I've tried many web-frameworks, so I may not be the best metric, but using MVC everything fell into place naturally and I'm happy to stick with it for now.
I don't think ASP.Net Forms is something you need to "get away from".
MVC certainly has it's usefulness and when appropriate certainly makes a lot of stuff simpler.
But a well designed ASP.Net Forms app can be just as or even more useful in certain situations.
Myself I use MVC for public facing sites and Forms for internal/administrative stuff.
For a data-heavy page, I think web forms is a perfectly adequate solution. MVC introduces separation of layers which may make it harder for you to develop, since it forces you to separate the gathering of the data and routing it.
I'd say MVC is nice for having an interactive web page (Web 2.0-ish) but if you are simply showing a bunch of reports, or making users fill out forms - there's not much for you to take advantage of, IMHO.
As an alternative, try writing less code with built-in controls like Repeaters or DataGrids or even DataSets. Getting down to the core of your data flow allows you to be more productive by writing smarter code - not necessarily by writing less code.
In the end, I've found that I put together my own "framework" that does exactly what I need. I get HTML directly from a custom control. These controls simply format the data being fed by procedure calls to my custom Database access class. And yes, these are all served up with web forms or http handlers (ASHX) and a little bit of jQuery.
So while it's not glamourous, it gets the job done faster and better - by developing code that is fine-tuned to my business, not to some abstract software design pattern.