FredZvt.WriteLines();

No-SQL – MongoDB – From introduction to high level usage in C# with NoRM.

fredzvt — Sat, 24 Apr 2010 19:26:38 +0000

Clique aqui para ler a versão original desse artigo em português.

First I would like to apologize in advance for my bad English. This is a translation of my original article in Portuguese. I will be grateful for any corrections.

In this article I’ll try to make an introduction to the No-SQL movement, the document oriented database MongoDB and three ways to use it: via shell, via the C# driver mongodb-csharp and via the NoRM library.

The objective of this article is that the reader becomes aware of what is and the basics of how to use MongoDB. For that, the examples that we will cover are intentionally simple and does not seek to explore the various ways to perform an operation on MongoDB either to demonstrate it’s full capacity.

Please keep in mind that I’m still studying the software and still do not have practical experience in projects using MongoDB, with my limited knowledge of my private studies, and although I’ve made every effort, using reliable sources, to ensure the veracity of informations until the time of this writing and tested on my computer all the code examples cited here, I can not give full guarantees. Constructive criticism and corrections are extremely welcome.

No-SQL
- No-SQL or relational databases!? Both!
MongoDB
- MongoDB vs CouchDB
- Installation and initialization of MongoDB server
Using MongoDB with Mongo shell
Using MongoDB with mongodb-csharp
Using MongoDB with NoRM
Updates after the publication of this article

No-SQL

Today there are several databases that break with the requirements met by traditional relational database management systems and these are their main characteristics:

The disuse of SQL as the query API. (Examples of APIs used include JSON, BSON, REST, RPC, etc.).
Does not guarantee atomic operations (non-ACID).
Distributed and horizontally scalable.
Abandonment to predefined schemas.
Non-tabular data storing (eg: key-value, object, graphs, etc.).

Note: Not all databases categorized as No-SQL possess all these characteristics, some have one, others another, some all.

The effort of development and evangelization community of these new technological approaches was named No-SQL and have been doing a lot of noise since early 2009. No-SQL should be understood as “Not only SQL” although this interpretation is not very obvious. In my opinion, it would make more sense if it had been labeled No-Relational.

The most complete listing of databases that can be framed as part of the No-SQL that I found is in http://nosql-database.org/. When I wrote this article, there were 47 databases distributed among different categories.

There is a nice introduction (in Portuguese) to No-SQL databases from the point of view of scalability in blog Escalabilidade.

Here I focus on MongoDB who, along with CouchDB, interested me the most since I started researching the subject.

No-SQL or relational databases!? Both!

Note that non-relational databases do not represent a complete substitution from relational databases. Ideally you must know the pros and cons of each approach and use the most adequate to your needs in the scenarios that we encounter.

I believe that the most obvious scenario that can be target of criticism is the scenario of reports generation. This cases are excellently resolved giving the best use of relational databases and Data Warehouse systems doing frequent aggregations of production data stored in non-relational databases.

Rob Conery wrote an excellent article about this topic.

MongoDB

MongoDB is a schemaless, document oriented, high performance, scalable database that tries to give the best of key-value stores, where documents are stored as JSON structured documents, and relational database management systems with features like many indexing models and dynamic queries.

His name comes from “humongous” (something giant), perhaps with a sarcastic tone to be such a tiny piece of software and so powerful or perhaps because it can scale up to become something really monstrous. Who knows…

Today is used in production for at least 40 sites of high performance and access, including sites like SourceForge, GitHub, EA and The New York Times.

MongoDB vs CouchDB

Although MongoDB and CouchDB have differences in their implementation approaches in aspects such as versioning and concurrency control, scalability, query API, etc, and although both are open source projects, I still consider them as competitors by offering similar features. I believe MongoDB has a great advantage and will develop more quickly because it is written in C++ and not in Erlang, like CouchDB.

Installation and initialization of MongoDB server

MongoDB can be downloaded in compiled versions for Linux, OS X and Windows. For the examples in this article I use version 1.4.0 compiled for Windows 64-bit but I believe that there are no differences using the 32-bit version.

When you finish downloading the zip file, unzip it into any folder on your computer. Four directories will be created: bin, include, lib and lib64. The folders include, lib and lib64 are used for those who will use MongoDB with C++, in our case what matters is the application mongod.exe inside the bin folder, which is the server of MongoDB.

By default, MongoDB uses the c:\data\db as default path to their databases files but this folder is not automatically created, so create them before running the server. If you prefer to use another folder to store your databases files, boot the server with the parameter ––dbpath [path]. I personally like to also use the parameter ––directoryperdb that causes MongoDB create a subfolder for each database that is created. Finally, running mongod.exe the server will initialize by default on localhost, port 27017.

Console with mongod.exe started and waiting for connections.

Next we’ll perform the four basic operations for manipulating data (CRUD) and simple queries on a test base in MongoDB using Mongo shell, in C# with driver mongodb-csharp and with the high-level library NoRM.

Using MongoDB with Mongo shell

The executable mongo.exe is the mongo shell. Run it without parameters and it’ll be initialized connected to the server in its default port (27017).

Enter the command show dbs and Mongo will list all databases that exist. By default there is admin, local and test. To change the database that will receive our commands, use the command use [database name]. The creation of new databases occurs automatically when we add some data to a database that doesn’t exists.

We’ll now insert our first document in our new base, effectively creating it. Enter the command use mybase, this will inform the shell that we will send commands to the database mybase, even if it not exists yet. At this time the base does not exist, you can confirm this executing the command show dbs again. Now we’ll use the command db.[collection name].save( [JSON document] ) to create and save a new document, note that the document should be written using JavaScript Object Notation (JSON). Enter the command: db.People.save({ name: "Fred", age: 28 }) and now the command db.People.save({ name: "Carlos", age: 30 }). Okay, now we have a base named mybase with a collection named People and two JSON documents in this collection: one representing a person named Fred with 28 years old and one representing a person named Carlos with 30 years old.

There are two additional limitations on JSON documents written to be stored by MongoDB: the names of the keys can not start with $ or have . (dots) in any place. Thus, documents such as { $test : 1 } or { “test.key” : “value” } will be invalid.

One of the most interesting features of some No-SQL document oriented databases (including Mongo) is the disuse of predefined schemas in documents of the same collection. In other words, a collection can have documents whose structures are completely different. For those who are familiar with relational databases where each document (record) structure (columns) is restricted by the table that contains it, this is a huge paradigm shift. To illustrate this, let’s add a new document in our collection that is not structured as the previous two that we include. Enter the command db.People.save({ firstname: "Joaquim", lastname:"Silva", age: "15 years old" }). With this command we just insert a document in the collection People with a structure completely different from previous documents and this is absolutely valid.

Now that we have data stored, its time to do some queries on them. In shell, the queries are primarily conducted by the command db.[collection name].find(...). If we execute this command without any parameters it will list all documents of a collection, so db.People.find() will return the three documents that we just inserted. The find command can be used in many ways, allowing us to run any queries that we imagine in our collections. This is a feature that makes MongoDB stand out amongst other No-SQL databases. To exemplify a little (very little indeed!) this feature, we’ll run a query with a simple criterion: to return only the document that represents the person named Fred we would run the command db.People.find({ name: "Fred" }). The find command is one of many that uses a JSON document as criteria specification to ensure that Mongo will apply the desired effect just in the documents that met this criteria.

Note that the returned document has a property beyond that stated explicitly: the _id property. Every document stored in MongoDB collection has to have a unique _id property. We can declare it explicitly in the creation of the document or MongoDB will automatically create an ObjectID typed property called _id for us. This property is the primary identifier of a document in MongoDB and will be indexed by default in all collections. The identifier property has no obligation to be of type ObjectID and may be of any type supported by JSON documents (BSON actually), but the use type ObjectID is recommended to facilitate the scalability of MongoDB databases.

To delete a document in a collection, we will use the command db.[collection name].remove([criteria JSON document]), therefore, to remove the document that represents the person named Carlos, we would perform db.People.remove({ name: "Carlos" }).

To update a document of the collection, we need to get the desired document first, modify it and save it back to the database, effectively updating it. The shell provides us a very useful command when you need to get a single document from a collection to handle it: the command db.[collection name].findOne([criteria JSON document]), so, by running the command joaquim = db.People.findOne({ firstname: "Joaquim" }); we will assign to the variable joaquim the document returned by the database. Now we can change it and save it again in the collection: run joaquim.lastname = "Souza"; to change his last name and db.People.save(joaquim); to update the document in the database.

In my opinion, the shell is the main administration interface to MongoDB, although its main use is through a programming language specific driver. All the features of MongoDB can be accessed from the shell, becoming intimate to this tool will greatly assist you to work with MongoDB databases. See the documentation for the shell on the official MongoDB.

Using MongoDB with mongodb-csharp

As shell is the interface between human-MongoDB the programming language specific drivers are the interfaces between software-MongoDB. Today there are drivers for 25 programming languages. Only for .NET framework, there are 6 drivers/tools according to Bryan Migliorisi in an article on his blog, and among these the MongoDB-csharp driver, developed by a troupe led by Sam Corder, is the most mature to date.

A small criticism to the project goes to the poor documentation, I think at least the wiki project should contain some examples of the major features but it is possible to understand how it works analyzing the test projects. I believe this will be greatly improved with some time as the project is still very young.

In this article we will use the version 0.82.2 of MongoDB-csharp to run our examples. Its API is very similar to the shell, making our lives even easier.

Unpacking the download file, we’ll have three libraries: MongoDB.Driver.dll, MongoDB.GridFS.dll and MongoDB.Linq.dll. The one which we must add as a reference in our project is the MongoDB.Driver.dll. The other two are, respectively, an API to support the GridFS specification, which allows storage of binary objects over 4MB in MongoDB and basic support for LINQ.

The first thing we must do in our code to use MongoDB is connect to server:

using MongoDB.Driver;

Mongo mongo = new Mongo();
mongo.Connect();

Then we get a reference to the database and the collection that we want to handle:

Database db = mongo.GetDatabase("mybase");
IMongoCollection collection = db.GetCollection("People");

The class MongoDB.Driver.Document represents a MongoDB document and works much like a System.Collections.Generic.Dictionary:

Document doc = new Document();
doc.Add("name", "Guilherme");
doc.Add("age", 22);

To persist a the new document in the referenced collection:

collection.Save(doc);

When we run the find command in shell, what we get in return is actually a cursor that is automatically iterated by shell but we could assign it to a variable and manipulate it manually. MongoDB-csharp uses the same principle, but here the work of iterating over the values will always be manual.

ICursor cur = collection.FindAll();
foreach (Document iDoc in cur.Documents)
{
    Console.WriteLine("Name: {0}, Age: {1}", iDoc["name"], iDoc["age"]);
}

To update a document, the process is, again, similar to run on shell: get a reference to a specific document, modify it and save it back to the collection:

Document doc2 = collection.FindOne(new Document() {{"firstname", "Joaquim"}});
doc2["lastname"] = "Silva";

collection.Save(doc2);

And, finally, to delete a document:

collection.Delete(doc2);
collection.Delete(new Document() {{ "name", "Guilherme" }});

Could it be more simple? The driver MongoDB-csharp provides APIs for almost all the features of MongoDB and is very easy to use, as we saw.

Using MongoDB with NoRM

After met the NoRM library, when I use MongoDB-csharp to access a database I get a bitter taste of low-level in my mouth, I remember the time when I use Recordsets to access databases in classic ASP.

The NoRM library provides a strongly typed, high level abstraction for manipulating documents in MongoDB as well as a friendly API to send commands to the server.

NoRM, as well as MongoDB-csharp, is an open-source project hosted on github, has Andrew Theken as leader and primary developer and contributors of the weight of Rob Conery (the mind behind the project SubSonic). It’s a project so young that even has a release yet, but already attracting lots of attention!

Because there are no releases so far, we have to download the code to compile on our machine. In the github’s project page, click the “Download Source” and then select the compression format of your preference. Save and unpack it in any folder on your computer. Or make a clone of the Git repository. Open the solution NoRM.sln, compile the NoRM project and add reference to the generated DLL into your application or add the project NoRM/NoRM.csproj to your solution and reference the project in your application.

The library works in a strongly typed manner, automatic translating your C# classes in BSON documents to store in MongoDB and vice versa, so let’s create the class Person:

class Person
{
    public ObjectId ID { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
}

NoRM imposes certain conventions in our classes to run serialization/deserialization without problems, they are:

The supported types for serialization/deserialization (until the moment of this writing) are:
- int
- bool
- double
- float
  - Will be always serialized/deserialized as double
- DateTime
- string
- byte[]
- Norm.ObjectId
- Regex
- Guid
- Enums
  - Must inherit from uint, int, ulong, long
- Norm.ScopedCode
- IEnumerable
  - T must be of one of these supported types as well.
  - Will be always deserialized as List
Its recomended that, when use value types, we should use use use their nullable versions because when the document been deserialized hasn’t a property of your C# class, this will be assigned to null. (Eg: use int? instead of int)


Every C# class must possess a public property called _id or ID, being of one of the supported types, but if we use Guid or Norm.ObjectId it initialization will be automatic.

If we want to use another property as our identifier we could use the [MongoIdentifier] attribute, getting rid of the requirement to create the property _id or ID.


All public properties must have public getter and setter. Update: As Andrew Theken inform Karl Seguin’s work has made private/protected getters/setters available.
NoRM still don't recognizes ciclic references, leaving for us clients to take care of this. Be warned, if this occurs it will generate an inifinite loop in runtime.
NoRM still don't recognizes if you try to deserialize a value in an invalid property type. (Eg: A type convertion error will occur if you try to deserialize a BSON integer value in a Datetime property.
The size of a document cannot be greater than 4MB. (In fact, this is a limitation of MongoDB, not of NoRM. If you must store a binary greater than 4MB, use GridFS specification)
The precision of DateTime type is in milliseconds. If you need more precision, use doubles instead.


I know that at first glance seems to have many restrictions but, in my opinion, for a project that has his first commit in January 30 of 2010, its quite an achievement. Remember that this library is open source and if you miss a feature that was not implemented you could submit a patch. Besides, all I need to implement my domain entities in plain POCOs are being offered at the library.
With everything in place, lets open a connection with MongoDB server an get a reference to our collection:
using Norm;
using Norm.Collections;

Mongo mongo = new Mongo("mybase");
MongoCollection Collection = mongo.GetCollection("People");

To insert a new person in our collection we just need to create an instance of Person and save it in our collection:
Person Bruno = new Person();
Bruno.Name = "Bruno";
Bruno.Age = 35;

Collection.Save(Bruno);

To update a document, we first get the document from the collection but this time in a strongly typed way. To specify the criteria we'll use a anonymous type with only a property called Name. Then we'll update our instance of Person and save it back to the collection:
Person Bruno2Update = Collection.FindOne(new { Name = "Bruno" });
Bruno2Update.Age = 40;
Bruno2Update.Name = "Bruno Garcia";

Collection.Save(Bruno2Update);

For beautifully list the persons in the collection:
IEnumerable People = Collection.Find();
foreach (Person p in People)
{
    Console.WriteLine("Name: {0}, Age: {1}", p.Name, p.Age);
}

And, finally, could not be simpler to delete a person from the collection:
Collection.Delete(Bruno2Update);


Updates after the publication of this article
The wide acceptance of this article was a big surprise for me and I would like to thank everyone who gave me some kind of feedback.
I would add some notes and corrections sent in by readers:
First of all, I want to clarify that in this article I'm not really giving preference to the driver mongodb-csharp nor the NoRM library. For me, it was clear that the two libraries are proposed to different things. While mongodb-csharp undertakes to provide the API in a manner more similar to the shell, giving us greater flexibility, NoRM proposed to provide greater productivity more distant to shell approach and closer to the reality of developers, providing a direct mapping of their classes in C# so strongly typed, however less flexible.
I was happy to be informed by Craig Wilson that soon we'll have a release of mongodb-csharp that brings feature parity with NoRM plus a little extra.
If the project mongodb-csharp is now proposed to offer all the features offered by NoRM project and vice versa, at first I will give preference to mongodb-csharp since I consider it a more mature project. But in that case, I don't understand why the two teams did not come together to develop a unique library, taking the best of the two worlds.
Finally, I inform you that there may be updates in the article body in order to better inform the readers with the informations that I receive. Where there is a fix, I'll strike through text and do inline comment.



No-SQL – MongoDB – Da introdução a utilização em alto nível em C# com NoRM.
fredzvt — Sun, 11 Apr 2010 01:35:21 +0000

Click here to read the english version of this article.

Neste artigo tentarei fazer uma introdução ao movimento No-SQL, a base de dados orientada a documentos MongoDB e três formas de utilizá-la: via shell, via o driver para C# mongodb-csharp e via a biblioteca NoRM.
O objetivo deste artigo é que o leitor tome conhecimento do que é e de como utilizar de forma básica o MongoDB, para isso os exemplos de utilização que percorreremos são intencionalmente simples e não visam explorar as diversas formas de se executar uma operação no MongoDB tampouco demostrar toda a sua capacidade.

Por favor, tenham em mente de que eu ainda estou estudando o software e ainda não possuo experiência prática em projetos utilizando o MongoDB, tendo meu conhecimento limitado por meus estudos particulares e, embora tenha feito todo o esforço para garantir em fontes confiáveis a veracidade das informações até o momento de sua escrita e testado em meu computador todos os exemplos de códigos aqui citados não posso dar maiores garantias. Críticas construtivas e correções serão extremamente bem vindas.
Conteúdo

No-SQL

No-SQL ou bases relacionais!? Os dois!



    MongoDB

MongoDB vs CouchDB
Instalação e inicialização do servidor do MongoDB


Utilizando o MongoDB com o Mongo shell
Utilizando o MongoDB com o mongodb-csharp
Utilizando o MongoDB com o NoRM
Atualizações após a publicação deste artigo


No-SQL
Existem hoje várias bases de dados que rompem com os requisitos clássicos atendidos pelos sistemas gerenciadores de bases de dados relacionais e tem como principais características:



O não-uso de SQL como API de consulta. (exemplos de APIs utilizadas incluem JSON, BSON, REST, RPC, etc.)
Não garantem operações atômicas (não-ACID).
Distribuídas e escaláveis horizontalmente.
O abandono aos esquemas pré-definidos.
O armazenamento de dados em um modelo não-tabular (ex: key-value, object, graphs, etc.)

OBS: Nem todos os bancos de dados categorizados como No-SQL possuem todas essas características, uns possuem umas, outros outras, alguns todas.

O esforço da comunidade de desenvolvimento e evangelização dessas novas abordagens tecnológicas foi nomeado de No-Sql e vem fazendo muito barulho desde o início de 2009. No-SQL deveria ser entendido como “Not only SQL” (Não somente SQL) apesar dessa interpretação não ser muito óbvia, em minha opinião. Faria mais sentido pra mim se tivesse sido rotulada de No-Relational.
A listagem mais completa de bases de dados que podem ser enquadradas como parte do movimento No-Sql que eu encontrei está em http://nosql-database.org/. Quando escrevi este artigo, haviam 47 lá distribuídas entre diversas categorias.
No blog Escalabilidade existe uma introdução bacana de bases No-SQL sob o ponto de vista de escalabilidade.
Aqui foco em MongoDB, que junto com CouchDB foram as que mais me interessaram desde que comecei a pesquisar sobre o assunto.

No-SQL ou bases relacionais!? Os dois!
Chamo atenção para que não pensem que bases não relacionais representam uma substituição as bases relacionais. O ideal é que você conheça os prós e contras de cada software e os utilize da melhor forma possível nos cenários que encontrar.
Acredito que o cenário de geração de relatórios computados sobre uma grande base de dados seja o alvo mais óbvio de críticas. Essas situações são resolvidas de forma excelente dando bom uso as bases de dados relacionais e sistemas de Data Warehouse agregando de forma frequente os dados armazenados em bases não relacionais dando suporte as aplicações de produção.
Rob Conery escreveu um excelente artigo sobre este tópico.

MongoDB
MongoDB é uma base de dados escalável de alta performance orientada a documentos com esquema dinâmico que tenta apresentar o melhor dos mundos entre os sistemas de armazenamento baseados em chaves/valores (key/values) onde os valores são estruturados como documentos JSON e os sistemas gerenciadores de bancos de dados relacionais atuais com recursos como vários modelos de indexação e consultas dinâmicas.
Seu nome, cá para nós brasileiros, soa muito mal. Mas, em inglês, vem de “humongous” (algo gigante), talvez com tom sarcástico por ser um software tão pequeno e com recursos tão poderosos ou talvez por ser escalável até se tornar algo realmente monstruoso. Vai saber…
Hoje é usado em produção por pelo menos 40 sites de alto acesso e performance, incluindo sites como SourceForge, GitHub, EA e The New York Times.

MongoDB vs CouchDB
Apesar de MongoDB e CouchDB apresentarem diferenças em suas abordagens de implementação em aspectos tais como versionamento e controle de concorrência, escalabilidade, API de consulta, etc, e ainda que ambos sejam projetos de código livre, ainda os considero como softwares concorrentes por oferecerem recursos similares. Acredito que o MongoDB leve uma grande vantagem e irá se desenvolver mais rapidamente visto que é escrito em C++ e não em Erlang, como o CouchDB.

Instalação e inicialização do servidor do MongoDB
O MongoDB pode ser baixado em versões compiladas para Linux, OS X e Windows. Para os exemplos deste artigo vou usar a versão 1.4.0 compilada para Windows 64-bits mas acredito não haver diferenças usando a versão 32-bits.
Quando terminar de baixar o arquivo zip, descompacte-o em uma pasta qualquer de seu computador. Serão criadas quatro diretórios: bin, include, lib e lib64. As pastas include, lib e lib64 são utilizadas para quem for utilizar o MongoDB programando em C++, no nosso caso o que interessa é a aplicação mongod.exe dentro da pasta bin, que é o servidor do MongoDB.
Por padrão, o MongoDB utiliza a pasta c:\data\db como caminho padrão para suas bases de dados mas essa pasta não é criada automaticamente, portanto crie-as antes de executar o servidor. Se preferir usar outra pasta para o armazenamento das bases, inicialize o servidor com o parâmetro ––dbpath [caminho da pasta]. Eu, particularmente, gosto de utilizar também o parâmetro ––directoryperdb que faz com que o MongoDB crie uma subpasta para cada base que for criada. Enfim, executando o mongod.exe o servidor será inicializado por padrão em localhost, na porta 27017.
Console com o mongod.exe iniciado e esperando por conexões.
A seguir, executaremos as quatro operações básicas de manipulação de dados (CRUD) e consultas simples em uma base de testes no MongoDB utilizando o Mongo shell, em C# com o driver mongdb-csharp e em alto nível utilizando a biblioteca NoRM.

Utilizando o MongoDB com o Mongo shell
O executável mongo.exe é o Mongo shell. Execute-o sem parâmetros e o shell inicializará conectado ao servidor MongoDB em sua porta padrão (27017).
Entre com o comando show dbs e serão listadas as bases de dados que existem: inicialmente admin, local e test. Por padrão o shell inicializa configurado para utilizar a base test. Para alterar a base que receberá nossos comandos, utilize o comando use [nome da base]. A criação de novas bases se dá automaticamente ao posicionarmos o shell em uma base não existente e inserirmos algum dado nela.
Vamos agora inserir nosso primeiro documento em nossa nova base, efetivamente criando-a. Entre com o comando use minhabase, isso irá posicionar o shell na base inexistente minhabase. Neste momento a base ainda não existirá, você pode confirmar isso utilizando o comando show dbs novamente. Agora vamos usar o comando db.[nome da coleção].save([documento JSON]) para criar e salvar um documento, note que o documento deverá ser escrito utilizando a notação de objetos em Javascript (JSON). Entre com o comando: db.Pessoas.save({ nome: "Fred", idade: 28 }) e agora com o comando db.Pessoas.save({ nome: "Carlos", idade: 30 }). Pronto, agora temos uma base de nome minhabase com uma coleção de nome Pessoas e dois documentos JSON nessa coleção: um representando uma pessoa de nome Fred com 28 anos e outro representando uma pessoa de nome Carlos de 30 anos.
Existem duas limitações extras em documentos JSON escritos para serem armazenados pelo MongoDB: os nomes das chaves não poderão iniciar com $ ou terem . (pontos) em qualquer lugar. Portanto, documentos como { $teste : 1 } ou { "teste.chave" : "valor" } serão inválidos.
Uma das características mais interessantes de bases de dados No-SQL orientadas a documentos é a não restrição de esquemas em uma coleção. Em outras palavras, uma coleção pode ter documentos cujas estruturas sejam completamente diferentes. Para quem está acostumado com bancos de dados relacionais onde cada documento (registro) só pode ter o formato pré-definido pela tabela que o contém, esta é uma grande mudança de paradigma. Para exemplificar isso, vamos adicionar um novo documento em nossa coleção que não se estruture como os dois anteriores que incluímos. Entre com o comando db.Pessoas.save({ primeironome: "Joaquim", sobrenome:"Silva", idade: "15 anos" }). Com este comando acabamos de inserir na coleção Pessoas um documento com uma estrutura completamente diferente dos documentos anteriores e é absolutamente válido.
Uma vez com os dados armazenados, o próximo passo será consultar esses dados. No shell, as consultas são realizadas através do comando db.[nome da coleção].find(...). Se executarmos este comando sem nenhum parâmetro ele irá listar todos os documentos de uma coleção, portanto db.Pessoas.find() irá retornar os três documentos que você acabou de inserir. O comando find pode ser utilizado de muitas formas, nos permitindo executar quaisquer consultas que imaginarmos em nossas coleções. Esse é um dos excelentes recursos do MongoDB em que ele se destaca de várias outras bases No-SQL. Para exemplificarmos um pouco (bem pouco mesmo!) este recurso, vamos executar uma consulta com um critério simples: para retornar somente o documento que representa a pessoa chamada Fred executaríamos db.Pessoas.find({ nome: "Fred" }). O comando find, além de outros comandos do MongoDB recebem como parâmetro um documento JSON como uma especificação de critérios para que o comando somente se aplique aos objetos da coleção que possuem propriedades que o satisfazem.
Note que o documento retornado possui uma propriedade além das que declaramos explicitamente: a propriedade _id. Todo documento armazenado no MongoDB possui um _id que será único para cada documento em uma coleção. Podemos declará-lo explicitamente na criação do documento ou o MongoDB irá criar automaticamente um objeto do tipo ObjectID e atribuir ao mesmo. Essa propriedade constitui o principal identificador de um documento no MongoDB e será idexado por padrão em todas as coleções. A propriedade _id não tem obrigatoriedade de ser um ObjectID, podendo ser de qualquer tipo suportado por documentos JSON (na verdade BSON), mas o uso de identificadores ObjectID é recomendado por facilitar a escalabilidade de bases MongoDB. 
Para excluir um documento da coleção, utilizaremos o comando db.[nome da coleção].remove([documento-critério JSON]), portanto, para removermos o documento que representa a pessoa chamada Carlos, executaríamos db.Pessoas.remove({ nome: "Carlos" }).
Para atualizarmos um documento da coleção, vamos antes buscar o objeto que desejamos alterar, modificar uma de suas propriedades e salvá-lo novamente na base, efetivamente atualizando-o. O shell nos disponibiliza um comando muito útil para quando precisamos obter um único documento de uma coleção para manipulá-lo: o comando db.[nome da coleção].findOne([documento-critério JSON]), portando executando o comando joaquim = db.Pessoas.findOne({ primeironome: "Joaquim" }); obteremos na variável joaquim uma instância do documento para manipulação. Agora podemos alterá-lo e salvá-lo novamente na coleção: execute joaquim.sobrenome = "Souza"; para alterar seu sobrenome e db.Pessoas.save(joaquim); para atualizar o documento na base de dados.
Ao meu ver, o shell é a principal interface de administração do MongoDB, embora seu uso principal seja através de drivers específicos por linguagem de programação. Todos os recursos do MongoDB podem ser acessados através do shell, tornar-se íntimo dessa ferramente ajudará muito o seu trabalho com bases de dados MongoDB. Veja a documentação do shell no site oficial do MongoDB.

Utilizando o MongoDB com o mongodb-csharp
Assim como o shell é a interface entre humanos-MongoDB os drivers são as interfaces entre softwares-MongoDB. Hoje existem drivers para 25 linguagens de programação. Somente para a framework .NET existem 6 drivers/ferramentas, segundo Bryan Migliorisi em um artigo em seu blog e, dentre esses, o mongodb-csharp, desenvolvido por uma trupe liderada por Sam Corder, é o mais maduro até o momento.
Uma pequena crítica ao projeto vai apenas para a documentação precária, acho que ao menos o wiki do projeto deveria conter alguns exemplos dos recursos porém é possível entender o funcionamento da maioria deles analisando os projetos de testes. Acredito que isso irá melhorar com o tempo pois o projeto ainda é bastante embrionário.
Neste artigo usaremos a versão 0.82.2 do mongodb-csharp para executar nossas operações de testes em nosso código. Sua API é bastante similar a do shell, tornando ainda mais fácil a nossa vida.
Descompactando o arquivo do download, teremos três bibliotecas dinâmicas: MongoDB.Driver.dll, MongoDB.GridFS.dll e MongoDB.Linq.dll. A que devemos adicionar como referência em nosso projeto é a MongoDB.Driver.dll. As outras duas são, respectivamente, uma API para a utilização do suporte à especificação GridFS, que permite o armazenamento de objetos binários com mais de 4MB no MongoDB e o suporte básico a LINQ.
A primeira coisa que devemos fazer em nosso código para utilizar o MongoDB é conectar ao servidor:
using MongoDB.Driver;

Mongo mongo = new Mongo();
mongo.Connect();

Em seguida, devemos obter uma referência à base de dados e à coleção que queremos manipular:
Database db = mongo.GetDatabase("minhabase");
IMongoCollection collection = db.GetCollection("Pessoas");

A classe MongoDB.Driver.Document representa um documento do MongoDB e funciona de forma muito semelhante a um System.Collections.Generic.Dictionary:
Document doc = new Document();
doc.Add("nome", "Guilherme");
doc.Add("idade", 22);

Para persistir um novo documento na coleção referenciada:
collection.Save(doc);

Quando executamos o comando find no shell o que retornamos é, na verdade, um cursor que é iterado automaticamente pelo shell mas que poderíamos referenciar em uma variável e manipular manualmente. O mongodb-csharp utiliza o mesmo princípio, mas aqui o trabalho de iteração sobre os valores será sempre manual.
ICursor cur = collection.FindAll();
foreach (Document iDoc in cur.Documents)
{
    Console.WriteLine("Nome: {0}, Idade: {1}", iDoc["nome"], iDoc["idade"]);
}

Para atualizarmos um documento, o processo é, mais uma vez, semelhante ao executado no shell: buscar uma referência a um documento específico, alterá-lo e salvá-lo de volta a coleção:
Document doc2 = collection.FindOne(new Document() {{"primeironome", "Joaquim"}});
doc2["sobrenome"] = "Silva";

collection.Save(doc2);

E, por fim, para excluirmos um documento:
collection.Delete(doc2);
collection.Delete(new Document() {{ "nome", "Guilherme" }});

Simples, não!? O driver mongodb-csharp nos proporciona APIs para quase a totalidade de funcionalidades do MongoDB e é muito fácil de ser utilizado, como pudemos ver.

Utilizando o MongoDB com o NoRM
Depois de ter conhecido a biblioteca NoRM, quando utilizo o mongodb-csharp para acessar uma base MongoDB fico com um gosto amargo de baixo nível em minha boca, lembro-me da época em que acessava bancos de dados com Recordsets em ASP clássico.
A biblioteca NoRM proporciona uma abstração em alto nível para a manipulação de documentos em uma base MongoDB de forma fortemente tipada além de disponibilizar uma API mais amigável para envio de comandos a um servidor MongoDB.
NoRM é um projeto de código livre, assim como o mongodb-csharp é hospedado no github, tem Andrew Theken como líder e principal desenvolvedor e contribuidores do peso de Rob Conery (a mente por trás do projeto SubSonic). É um projeto tão novo que nem release tem ainda, mas que já chama muita atenção!
Pelo fato de não ter saído release ainda, somos obrigados a baixar o código para compilarmos em nossa máquina. Na página do projeto no github, clique no botão “Download Source” e, em seguida escolha o formato de compactação que preferir. Salve e descompacte em alguma pasta de seu computador. Ou faça um clone do repositório Git — Tino Gomes ensina como fazer isso no Windows). Abra a solução NoRM.sln, compile o projeto NoRM e referencie a DLL gerada em sua aplicação ou adicione o projeto NoRM/NoRM.csproj a solução da sua aplicação e referencie o projeto adicionado.
A biblioteca NoRM funciona de forma fortemente tipada, fazendo a tradução automática entre documentos BSON armazenados no MongoDB e suas classes em C# e vice-versa, portanto, vamos criar a classe Pessoa:
class Pessoa
{
    public ObjectId ID { get; set; }
    public string Nome { get; set; }
    public int Idade { get; set; }
}

NoRM impõe certas convenções em nossas classes para que a serialização/deserialização seja realizada sem problemas, são elas:

Os tipos suportados para serialização/deserialização (até o momento em que este artigo foi escrito) são:

int
bool
double
float

Sempre será serializado/deserializado como double


DateTime
string
byte[]
Norm.ObjectId
Regex
Guid
Enums

Deve herdar de uint, int, ulong, long
 (ex: public enum meu_enum : int {...})

Norm.ScopedCode
IEnumerable

T deve também ser de um dos tipos suportados
Sempre será deserializado como List Atualização: Como informou Andrew Theken, parece que agora temos a opção de utilizar outros tipos de coleções.




É recomendado que ao usar tipos de valor (value-types) deveremos ancapsulá-los em um System.Nullable pois se o valor da propriedade não existir no documento BSON, será atribuído null. (Ex: usar int? ao invés de int)
Todas as classes devem possuir uma propriedade pública chamada _id ou ID sendo de qualquer um dos tipos suportados, porém se forem do tipo Guid ou Norm.ObjectId não precisaremos inicializar este valor em uma instância pois NoRM se encarregará disso.

Caso queira utilizar uma outra propriedade qualquer como identificador de seu documento poderá utilizar o atributo [MongoIdentifier] para tal, livrando-se da obrigatoriedade de criar uma propriedade _id ou ID


Todas as propriedades públicas deverão possuir acessores get e set. Atualização: Como informado por Andrew Theken, o trabalho de Karl Seguin tornou possível a utilização de propriedades públicas com get e set private ou protected.
NoRM ainda não reconhece referências cíclicas entre classes deixando por conta do programador tomar cuidado com isso, caso contrário a execução da aplicação entrará em loop infinito.
NoRM ainda não resolve casos de tentativa de deserializações de tipos inválidas, por exemplo, se tentarmos deserializar um valor BSON inteiro em uma propriedade DateTime um erro de conversão será gerado.
O tamanho do documento BSON não poderá ultrapassar 4MB. (Na verdade uma limitação de qualquer documento armazenado no MongoDB que não use a especificação GridFS)
Os tipos DateTime terão precisão de milisegundos. Se presisarmos de mais precisão deveremos utilizar double.

Sei que a primeira vista parecem muitas restrições mas ao meu ver, para um projeto cujo primeiro commit data de 30 de janeiro de 2010, é um feito e tanto! Lembre-se de que, se precisarmos de algo que a ferramenta não ofereça recurso poderemos criá-los e submeter um patch ao projeto. Além disso, tudo o que preciso para criar minhas entidades de domínio em POCOs está sendo atendido.
Com tudo em seu lugar, vamos abrir uma conexão com o MongoDB e buscar uma referência a nossa coleção de pessoas:
using Norm;
using Norm.Collections;

Mongo mongo = new Mongo("minhabase");
MongoCollection Collection = mongo.GetCollection("Pessoas");

Para inserirmos uma nova pessoa em nossa coleção bastará criar uma instância de Pessoa e salvá-la em nossa coleção:
Pessoa Bruno = new Pessoa();
Bruno.Nome = "Bruno";
Bruno.Idade = 35;

Collection.Save(Bruno);

Para atualizar um documento, buscamos, desta vez de forma fortemente tipada, a instância de Pessoa que queremos alterar passando como parâmetro de busca um tipo anônimo somente com a propriedade Nome, alteramos e salvamos novamente na coleção:
Pessoa Bruno2Update = Collection.FindOne(new { Nome = "Bruno" });
Bruno2Update.Idade = 40;
Bruno2Update.Nome = "Bruno Garcia";

Collection.Save(Bruno2Update);

Para listarmos as pessoas da coleção lindamente:
IEnumerable Pessoas = Collection.Find();
foreach (Pessoa p in Pessoas)
{
    Console.WriteLine("Nome: {0}, Idade: {1}", p.Nome, p.Idade);
}

E, por último, para excluirmos uma pessoa da coleção, nada mais simples:
Collection.Delete(Bruno2Update);


Atualizações após a publicação deste artigo
A grande aceitação deste artigo foi uma grande surpresa para mim e eu gostaria de agradecer a todos que me deram algum tipo de feedback.
Gostaria de adicionar algumas notas e correções enviadas pelos leitores:
Antes de tudo, gostaria de deixar claro que neste artigo eu não dou preferência ao driver mongodb-csharp nem a biblioteca NoRM. Para mim ficou claro que as duas bibliotecas possuem diferentes propostas. Enquanto mongodb-csharp provê uma API de uma maneira mais similar ao shell, nos dando grande flexibilidade, NoRM se provê maior produtividade com uma abordagem um pouco mais distante do shell mas mais próximo das necessidades reais dos desenvolvedores, provendo um mapeamento direto das classes em C# de forma fortemente tipada, porém menos flexível.
Fiquei feliz em saber pelo Craig Wilson que logo teremos uma versão do mongodb-csharp que trás todos os recursos disponíveis pelo NoRM e algo mais.
Se o projeto mongodb-csharp se propôr a oferecer todos os recursos oferecidos pelo projeto NoRM e vice versa, a princípio eu daria preferência ao projeto mongodb-csharp visto que este está numa fase mais madura. Mas nesse caso não entendo porquê as duas equipes não se juntam e desenvolvem uma única biblioteca que traga o melhor dos dois mundos.
E, finalmente, informo que podem haver atualizações no corpo do artigo para que possa informar melhor os leitores das informações que tenho recebido. Onde houver uma correção, tacharei o texto e farei comentários.

         


Abra o prompt de comando direto de uma pasta no Windows Explorer (Windows 2000+).
fredzvt — Tue, 30 Mar 2010 09:29:19 +0000
Essa dica será útil a todos que estão cansados de abrir o command prompt do Windows e ter que navegar manualmente até uma pasta específica para realizar uma tarefa.

Existem diversas maneiras de adicionar um comando no menu de contexto do shell do windows (veja esse blog post para uma descrição de vários métodos) mas, que eu saiba, nenhuma melhor ou mais simples e prática do que a pequena aplicação desenvolvida pelo simpático chinês Kai Liu. E ainda coloca uma opção para abrir o prompt como administrador em casos de Windows que utilizam o UAC (Windows Vista, Windows 7, etc.).
Open Command Prompt Shell Extension

         


Transforme seu laptop com Windows 7 em um Wi-Fi hotspot com o Connectify.
fredzvt — Sun, 28 Mar 2010 18:06:14 +0000
Descobri hoje uma ferramenta excelente, o Connectify.
Esse pequeno aplicativo transformou meu laptop com Windows 7 Ultimate em um ponto de distribuição da minha internet 3G quase como mágica! Agora eu e minha esposa podemos utilizar simultaneamente a internet, cada um em seu laptop.

O único problema que eu tive foi que o Windows XP do laptop da minha esposa não conseguiu conectar a rede com segurança WPA2-PSK mas que resolvi com tranquilidade, habilitando o modo Ad-Hoc WEP, que estava escondido e apareceu quando eu cliquei com o botão direito sobre o logo da aplicação Options > Show all settings.

FredZvt.WriteLines();

No-SQL – MongoDB – From introduction to high level usage in C# with NoRM.

Contents

No-SQL

No-SQL or relational databases!? Both!

MongoDB

MongoDB vs CouchDB

Installation and initialization of MongoDB server

Using MongoDB with Mongo shell

Using MongoDB with mongodb-csharp

Using MongoDB with NoRM

Updates after the publication of this article

No-SQL – MongoDB – Da introdução a utilização em alto nível em C# com NoRM.

Conteúdo

No-SQL

No-SQL ou bases relacionais!? Os dois!

MongoDB

MongoDB vs CouchDB

Instalação e inicialização do servidor do MongoDB

Utilizando o MongoDB com o Mongo shell

Utilizando o MongoDB com o mongodb-csharp

Utilizando o MongoDB com o NoRM

Atualizações após a publicação deste artigo

Abra o prompt de comando direto de uma pasta no Windows Explorer (Windows 2000+).

Transforme seu laptop com Windows 7 em um Wi-Fi hotspot com o Connectify.