Thoughts from the Wet Coast
The musings of an ASP.NET Developer from Canada's We(s)t Coast
In the first post in this series I pointed out that DotNetNuke places few requirements on module developers, and this is often daunting to new developers – “where do I start?” being a common refrain.
So where do you start?
Before we actually start to build our first module lets look at what constitutes a module. In the default DotNetNuke skin/template that is used when installing DotNetNuke there are a number of examples of Text/HTML modules.
DotNetNuke has a rich eco-system of Modules, both Open Source and Commercial. In many ways this is our biggest strength as a CMS platform. No matter what you want to do with your site – there is often a module that already does it.
In my opinion this is due to the flexibility provided by the core DotNetNuke Framework. Many other platforms are very prescriptive – as an extension developer you have to follow a fixed shopping list of rules – there is invariably only one way to create an extension, which may not work for what you want to do.
Today Scot Guthrie, Corporate Vice President in the Microsoft Server and Tools Business announced in a blog that some of the ASP.NET technologies that are used by web developers, including me, were to be made available under an open source license.
In my previous post in this series on NoSQL Databases, I showed how RavenDB embedded could be added to an existing ASP.NET MVC 3 application using NuGet and how it can be configured to use a folder in the App_Data folder.
In this blog I will add the code needed for my TaskController class to use RavenDB to store its data.
In my continuing series on NoSQL Databases I have been mainly describing some of the concepts behind NoSQL (and in particular Document) Databases. In this post I will start to dive into some code.
As mentioned earlier I will be using RavenDB as this is a .NET friendly database.
As my frequent readers would have noticed already, I have been diving into NoSQL databases recently – in particular Document Databases. But why do we need NoSQL databases in the first place. Surely the relational databases we have been using work fine – in fact they work very well in most situations.
The problem with them is they don’t always scale very well – and when I mean scale, I mean scale really big – across multiple nodes in a cluster. I alluded to this in the first post in this series, but as an aside I have decided to explore why in further detail in this post.
In my continuing research into NoSQL databases I needed to find a database to work with. As a .NET developer I was immediately drawn to RavenDB – a Document Database written in .NET by Ayende Rahien of NHibernate and Rhino Mocks fame.
A week or so ago the topic of NoSQL databases came up at a discussion at work, so I decided it was time I learnt about this topic.
A few days ago Julie Lerman (@julielerman) tweeted that she had published an article in MSDN Magazine on Document Databases (one of the major types of NoSQL databases) and reading that article started me on my research.
Most .NET developers, whether we work on the Web with ASP.NET Web-Forms or MVC, on Windows Phone or in the browser with Silverlight, or on the desktop with WPF have worked with some form of Database.
We are for the most part familiar with SQL Server, MySQL or Oracle Relational Database Management Systems (RDBMSs) – and we are used to writing database schemas and database code using some variety of SQL.
A few months ago I blogged about my plans to create a Windows Phone application based on my Family Tree Research hobby.
Well after a 5 month delay I finally submitted the first version of the application to the Windows Phone Marketplace today. I have made a few changes since my initial Blog Post. The most obvious change is that I added support for multiple GEDCOM files. The reason for this change was mainly for performance reasons.
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.