Thoughts from the Wet Coast
The musings of an ASP.NET Developer from Canada's We(s)t Coast

In my investigation of the Neo4j database I will now turn my attention to the Neo4j browser.  

Once Neo4j is installed there will be a small executable that can be used to start the Neo4j database server.

In this blog post I am going to return to my investigation of the graph database Neo4j.  So far I have done a brief introduction to Neo 4j and I have shown how easy it is to install Neo 4j in an Azure VM.

A couple of months ago I blogged about Neo4j, a graph database that I plan to check out.  I didn’t get much chance to play with it, and a couple of weeks ago I found myself having to re-install Windows on both my desktop computer and my Surface Pro.

As an ASP.NET MVP I get 160 credits per month of Azure services, enough to run 2-3 small VMs, so I thought it would make sense to install Neo4j on an Azure VM so it would be accessible whichever computer I was working at.

Over the last couple of years I have been trying to get a handle on the “new” database technologies lumped together under the NoSQL banner.  In that respect I have posted several articles to this blog.

More recently my focus has shifted from looking at NoSQL databases as a group to diving in deeper to a few select “NoSQL” databases.  The one that intrigues me most is Neo4j – a graph database.

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.

In a number of articles last fall I discussed NoSQL Databases in general and showed how RavenDB – a .NET NoSQL Database - could be used as the Data Store for an ASP.NET MVC Application.

In this article, I will demonstrate how RavenDB can be used as the Data Store for a DotNetNuke Module.