I was suggested to use BreezeJs for an AngularJs project and I saw that it has some really interesting features.
In my case the main interests would be in caching, tracking changes, some light querying, and validation.
I think those features can be implemented at some level in AngularJs without too much trouble:
Caching can be accomplished by storing the data, or API calls results in objects in services? Given the services nature, the data will be accessible throughout the app, and they will be cached.
Tracking changes is done by angular with 2-way data binding. Here you may drop some of that 2-way binding(less watchers in Angular), but Breeze will do that checking in parallel.
Queries are something I don't need to be very complex, so Angular filters will do the work. The same thing applies to validations, I have enough from Angular.
For data handling I saw that the EntityManager can be really handy.
I get the feeling that for applications, not too complex, you can achieve almost all the things BreezeJs offers directly in AngularJs, in a nice clean way, without the need of adding one more library.
What am I missing from BreezeJs?
You're missing just about everything ;-)
Angular doesn't do any of the things you mentioned.
Breeze caching ensures entity identity, just-in-time maintenance of navigation properties, entity dirty-checking, query-over-cache, and much more. None of that in Angular "cache".
Angular doesn't track changes to entities. It tracks changes to visible bindings; if it ain't on screen, it ain't tracked. Once it is no longer on screen, the "tracking" is gone. There is no notion of model change-state in Angular.
Angular filters are for in-memory filtering, not querying a server (or a cache).
Angular validations are purely HTML-facing. They don't validate the model. They do not prevent attempts to save invalid entities. They offer no means to answer the question "is this entity-or-property valid and if not, how is it invalid?". With ng you ask about the validity of forms, not entities. It can't help you enforce a business rule everywhere; the best you can do is try to decorate every HTML element that touches a model property with every business rule applicable validation (which may mean minting custom directives for your custom validation rules). Good luck with that.
I am not knocking Angular at all. Angular concentrates on functionality you need to organize your application and interact with HTML. It throws in $http to make server requests but that's as far "down" into the model layer as it goes. In fact, it quite deliberately (and properly IMO) makes no assumptions about the model. Therefore, it cannot do the things that Breeze does nor should it.
If you want to delve a bit deeper, you might look at the slides I presented at ngConf 2014 that try to explain what Breeze does and the synergy between Angular and Breeze.
I don't know whether you need Breeze for your application. But there is nothing in Angular that approximates Breeze. So if you want the functionality in Breeze you have two choices:
use Breeze
roll your own framework, leveraging whatever you can from ng (of which little is directly applicable).
Hope that clarifies.
Related
I have built an Angular app that consumes data from different sources (SharePoint lists). I setup a controller for each source.
What is the best practice for this? Use only one controller for the app and different services? Or one service and one controller? Or multiple services and controllers?
In the app I do not use routing.
First I'd recommend reading these articles. Also, go through their angular implementation and see how they've achieved some of their effects. It will throw you in a world of problems that you'll feel like "Why? I mean, why? why did I ever got into this mess?" But, grit your teeth and get through it. Then you'll see how much you can achieve. Learning Angular JS is a never-ending cycle of this.
angularjs-best-practices-directory-structure
Angular Style Guide
Advanced Design Patterns and Best Practices
The Top 10 Mistakes AngularJS Developers Make
Ok, and to answer your question: your way isn't wrong.
But controllers are not designed to be used like that. Controllers are a unit of code which co-ordinates your data into the UI, handle UI events, etc. generally of a certain view - i.e. a portion of your UI (navigation bar, home page, edit form, etc.). Of course this can be your entire page as well. But it's best to break it down so that it's easier to manage.
Use services for what you described. Create a service for each data source or type of data (users, equipment, roles, etc.). I recommend that latter, since sometimes you need to pull data from multiple ends and tie them together. This can be done inside your controller as well, but having services will enable you to re-use that functionality in another part of your application.
To summarize a long answer, I'd say go through these articles, code and tips. Then build a structure that will help build your application. Just don't over-engineer it.
I would say: use a controller for every "piece" of HTML in your app, (and it depends on the scale of your app how big that piece is, it could be just one controller if your app is really small). And use a service for each data source. Then you can use the services your need in your controllers. You could also use one service if you don't need a lot of behavior. It all depends on how big your application will be.
I am creating an ExtJS 4 single-page web application, and coming across some issues deciding on the MVC-favoured way of defining and maintaining my application state. I am aware of the global nature of ExtJS 4's stores, and I like the idea of them, but the practicalities of them are called into question on a couple of points.
For example, I have models that could possibly need to scale into the thousands at some point, and the idea of loading all of these into the memory of the client's browser does not strike me as the best of ideas. I would have great performance concerns with trying to do this.
Additionally, my application will have windows, multiples of which that may be viewed at the same time, in addition to multiple grids on the same tab in a tab panel. These views are supposed to show a subset of the models based on their properties. If these views are tied to the same global store and its models, they will be affected by operations such as filter and will effectively be restricted to showing the same set of models, which is not what I am trying to achieve.
So my actual question is how do I go about handling this situation? I have read a similar concern on StackOverflow that called for the views to hold their own instance of the store rather than using the global instance, but I am not sure this fits the MVC pattern correctly. My current thinking is along the lines of having a controller that manages the state and holds the various instances of the stores so they are not directly tied to the views and yet they can still be accessed on event calls and by other controllers. Is this a good solution or am I missing something?
Well, there's a lot going on in your question. First of all, I think you are over-thinking stores a bit. Ultimately, a store is just a cache of model instances. So you can create as many instances of them that you want, depending on the requirements of your application. If you want to try to use a single store to manage the entire data set, you can certainly do that, but you'll have to be VERY aware and vigilant in keeping track of filters/sorters/etc that you apply throughout the flow of your application.
Re: the scale of your application's data, I would strongly suggest not trying to load all your model instances in at the same time (depending on the size and complexity of data, of course). Unless you actually need all possible instances available in the application at all times, I would adopt an approach that loads only what you need, depending on the scenario. If you need access to thousands of records, you can always apply remote filters to still deal with the whole data set on the server side, but only actually interact with a subset of the data on the client side.
Ultimately, I wouldn't worry so much about whether or not a particular approach "fits" the MVC pattern (which is itself a very particular flavor in Ext JS, a flavor not desired by everyone...). Yes, you want to create an approach that is extensible and manageable; however, I would argue that the requirements of your application should drive how you utilize the MVC conventions that Ext JS 4 provides, rather than allowing the MVC conventions to determine your business requirements.
The JavaScript codebase we are using on our website is pretty well structured (outlined here if anyone's interested).
I have been looking at integrating backbone.js (or knockout.js, for some of the features) into our code -- but after closer considerations I don't think I care that much about data binding (my appliation does not do intensive client<->server data exchange, its more biased towards server->client->js data pipe), so I don't really care if I don't have dynamic data binding and syncing.
As I am not closely familiar with those libraries, I am afraid that by opting-out of using those libraries, I am missing some other vitally helpful features. Am I?
Personally I'd use backbone if I was building a full blown single-page web-app. If your website is primarily HTML, but uses JS for some minor added functionality I'd not worry about it. Backbone is good at handling client-side data models and tying changes to those to view updates.
Personally, I've used knockout and found it's reliance on data-binding in the HTML confusing. It wasn't something that worked well for me. It might be a little bit more friendly to building websites that are partially dynamic, because a lot of the logic goes right into the html view layer. You may want to listen to this recent podcast interview the creator of knockout as it may shed some light on things. http://javascriptjabber.com/
In my case, when building a big website with some dynamic elements I've stuck with the pattern of some global jQuery plugins and page specific JS. It works well enough for simple additions to specific pages.
I don't know if this question is super specific, so here's a generic answer :)
I'd first like to point out that while declarative databinding is the key feature for KnockoutJS, it is not a part of the core-backbone framework. There do exist multiple plugins like (Rivets.js and Orchestrator) which provide such functionality in Backbone JS.
Now coming to the primary aspect of your question - In terms of advantages other than Data-binding KnockoutJS does not have much to offer. However even if interactive data binding is not a primary concern you should definitely consider using BackboneJS. The reason for that is Backbone comes bundled with a client side routing system and a succinct but minimal approach towards managing Data obtained from the server in javascript.
As you have mentioned that your application is data-driven, probably the data that you have fetched in the client is not fetched all at once but is incrementally updated. In that scenario, having observable Models and collections might help you to manage your in-app data-dependencies well (as well as keep any widges for visualizing the data in sync.)
I want to develop a relatively simple application that calculates some value based on several inputs. I dont want a backend, all the calculation can be done in the browser.
Im a little new to JavaScript and WebApps and I came across Backbone.js.
I really like the MVC design, however, they mention a backend a lot. My question:
Is a backend server absolutely required?
Is a backend server optional but without one there isn't much point in backbone.
Or will backbone will really help me out?
Backend is not required.
Backbone can fully work without any backend if your application doesn't require one.
That depends on your application. If you want to retrieve value of some inputs and calculate a result then Backbone won't do that for you - it will help you structure your code. If you app is simple and don't need support for models, views and collections or routing, then there is no point in using Backbone. Hard to answer this question.
For example: Classic todo example application doesn't use any backend.
Backbone.js implements fetch(), save(), destroy() etc. methods on models automatically performing appropriate AJAX requests and parsing response. So it has a strong support for backend via REST services, but it is optional.
You can still use models, views, routers and events without any server-side code. Just don't call REST methods (or override them at your wish).
You can use localStorage for persistence (you'd have to implement this yourself or find it on the web, like here) but if you don't even need that then you don't need to use any of the persistence methods in backbone.
Backbone is meant to help you structure a medium-large sized application (js-wise), so it doesn't become unmaintainable jQuery spaghetti. With short applications (js-wise) it's really an overkill unless you are trying to learn how backbone works.
Note with js-wise I mean the client side code, if you had a huge backend but the only js would be something that focuses some form, it would not even count as a short application (js-wise).
You can use backbone.js without a backend. However you obviously won't be able to store or retrieve data. Backbone may still be useful for keeping your code organized, however it really shines when you want to separate presentation logic from logic that manipulates your data, which is a goal of the MVC pattern. Generally your data will be stored on and retrieved from a backend.
If you want to play around with data persistence, try out backlift.com. [disclosure, I work on backlift.com] We've tried to make it easy to get a backbone app up-and-running without having to setup a server or deal with compiling templates.
I'm searching for a simple architecture for my UI that will have some basic javascript functions in like: select all checkbox's, image crop, some pop-ups and some other plugins.
I found this article: Organizing Your Backbone.js Application With Modules
My application is not a SPA (Single Page Application). I want to know if Backbone.js with jQuery will help me even if my application is not a SPA.
The strength of Backbone is really in its ability to manage many models (even complex ones) and keep the rendered page in sync with their current values. It provides an interface to getter/setter functions so that the changing of a model value (there are many different flavors of "change") will call render on the corresponding view and the page will correctly reflect the underlying models. Furthermore, it provides interfaces to saving, paging, and routing actions on models.
I have used Backbone extensively for both SPA's (where it shines) as well as more traditional, multiple page applications. It has no special support for UI and DOM manipulation, but combined with jQuery/Prototype/Zepto it manages their rendering/manipulation.
Basically, backbone works best to untangle elaborate chains of rendering logic and model updating. If you feel that your application has a lot of view elements that need to stay in sync with models that the client will be updating on the page, Backbone is a wonderful solution. If you just need to select and manipulate DOM elements, it's overkill. jQuery alone can handle that.
Backbone is really not about the things you mentioned, but I wouldn't say it is strictly for single-age apps (SPA) either. I'd say it is for any case where you've got quite complicated pages and it would benefit you to break them up into multiple pieces (for example, several views that all pull data from one model).
However, I would say the strength of Backbone.js is in the SPA realm.
You could probably find some jQuery pieces that answer some of your needs if you're not already using jQuery as part of your app. However, jQuery is all about the parts you mentioned (easy DOM manipulation, popups if you use jQuery UI, etc.) and not about structure or organization.
I believe that the principal idea of backbone, is organize you JS code in complex app using the MVC concept.
This way your app becomes easier to mantain and add new features, It get easy to use frameworks tests like jasmine.
Backbone also make possible (and very good) work based on SPA approach, using ajax request to server. It is completely based on Restful concept, to get a code using backbone, is important to understand what is Restful.
Basically Backbone have a Router (that can work like a controller. but is not a controller).
Model that is where you can manage all the data logic of your application.
Collection that is like a list of models.
View that is where you will react accordingly the model changes.
There are other things, but basically, is this.
But as I said before, you can use it without have a SPA.
The most important thing to have in mind is that the concept of MVC must be followed when using backbone. If you don't do that, it doesn't make sense use backbone.