So far in this series on Knockout.js we have seen how to do simple data-binding and how to use observables to automatically update the data bound elements. The real power of knockout though is its support of two-way data-binding.
What do we mean my two-way data-binding?
ASP.NET developers are familiar with the concept of data-binding - the ability to bind a control to a data source and update the control based on the value of the data source. Two way data-binding allows the control (View) to update the data source if its value changes.
In the previous post in this series I introduced the concept of simple one-way data binding. However the real power of knockout is its support of observables and two-way binding.
The concept of observable objects or observable collections was developed for WPF (Xaml) and Silverlight.
In the first part of this blog series on Knockout.js, I introduced the MVVM (Model-View-ViewModel) nature of the framework. In this second post I will show how Knockout’s data-binding works.
Last year, when I blogged on NoSQL databases I briefly described the types of databases that are usually encompassed by the term NoSQL Databases. In that series of blogs I reviewed three types of databases, Key-Value Databases, Column-Oriented Databases and Document Databases, before focusing my attention on RavenDB – a document database.
In this blog, I will introduce a fourth class of NoSQL Database – Graph Databases. While Graph Databases are NoSQL Databases they are significantly different from the other three classes of NoSQL Databases. Graph Databases are based on the mathematical concepts of graph theory.
BigData – it seems to be a technology area that is in vogue. It encompasses technologies such as Hadoop, Hive, Pig and Sqoop – yes they all seem to have funny names.
Every quarter, in the Engineering dept. at DNN Corp, we have quarterly reviews where we review with our manager the previous quarter’s objectives and establish objectives for the upcoming quarter. At the beginning of this year one of my objectives was to become more familiar with these BigData technologies and determine which if any we need to be aware of.
About 18 months ago I started a series on NoSQL Databases. I haven’t blogged much on them for about a year, but recently I have been reading quite a lot recently about Big Data and NoSQL and my intentions is to continue blogging as I learn.
I continue my deep dive into DotNetNuke 7’s new DAL 2 with a look at the features that make up the repository component.
The IRepository of T interface can be considered the core of the new DAL 2. While the Execute methods of the IDataContext interface provide a DAL + like API, the benefits of the new API are really found when using the repository. The Repository Pattern is a common design pattern in modern data access layers.
So far I have done a relatively high level review of the DAL 2 API. In this blog article I will start to take a deep-dive into the components that make up the API, beginning with the DataContext.
The IDataContext interface and the PetaPocoDataContext concrete implementation act as the entry point into most aspects of the DAL 2 API. While implemented as an Interface there is no expectation that any other implementation will be created, but the interface allows us to mock a concrete implementation for Unit Testing purposes.