Strongly-typed Data Class Pros and Cons

[Tom Larry]

In the OOP and RDBMS world, we usually create a strongly-typed data class to represent the table schema. For example, table Books(BookID int, BookName varchar(50), ...) would be:

public class Book

{

  public int BookID {get; set;}

  public string BookName {get; set;}

  ... // including all kinds of methods and properties such as update/fetch

}

public class Books

{

  public Book MyBook {...}

  ... // including all kinds of manipulation of Books 

}

UI developers will deal w/ these classes for data manipulation. However, sometimes it's very tedious to maintain that we start just deal w/ stored proc only.

With MongoDB, first of all schema is dynamic, the only way I can think of is:

public class Book

{

  public int BookID {get; set;}

  public string BookName {get; set;}

  public List<BsonDocument> OtherBookThingy {...}

}

My question is:

 1) Can this mapper serialize data into strongly-typed can be skipped for dealing w/ MongoDB as we don't know the exact schema?

 2) A wrapper like above maybe good to hide all DB details such as table relationship, but has added a new layer supposed result slower performance. Now MongoDB has no cross table relationship, meaning always a single table(collection). What if just build a small class to hide the details of database connection to MongoDB? This should be good enough, UI developers can use native MongoDB C# driver to query and upsert data for better performance, right?

[s.molinari]

Check out these Mappers.

http://mongodb.github.io/morphia/

http://mongolink.org/

Although MongoDB has flexible schema, it doesn't mean "no schema", which many people mistakenly think NoSQL means. Your application should be aware or in control of the schema at all times. For that you can use a mapper.

Scott