MongoDB Paris 2012: Exploring Design Patterns with MongoDB

Most current MongoDB design discussions are on schema design and infrastructure design. In this presentation we'll instead explore the slightly underestimated classic application-level design patterns for writing code that integrates well with MongoDB as a database backend. We'll be applying traditional design patterns to MongoDB such as ActiveRecord, Inversion of Control, and Repository patterns, and touch on potential pitfalls when working with MongoDB over a relational database. Code examples are in C#, but will be applicable to similar object oriented languages.

Transcript

1. Exploring design patterns with MongoDB TAMING THE HORSEPOWERS Morten Holk Maate Sr. Developer, Product Manager mhm@configit.com
2. db.GetCollection(''Employee'').Save(employee);
3. One reason that MongoDB is great is that our data store uses objects – as well as our OO programming language uses objects JSON in Mongo Shell: C# in Visual Studio:
4. … and objects do seem like a great abstraction for … objects
5. MongoDB Solves The Object-Relational Impedence Mismatch • Data Mapping • Normalization • Object Identity • Serialization Storing Objects as Objects Utilizing Object Hierarkies With ObjectId() As BSON
6. Your Object is not your Object! Is NOT equal to this: And this:
7. Literally 
8. EXPECTATIONS • Data Mapping • Normalization • Object Identity • Serialization REALITY • C#/Java objects still needs some mapping to become Mongo Objects • C#/Java objects still needs some normalization • We have not solved the identity problem • Serialization still is not easy
9. Hands on case: Storing employees in a database Take 1 Illustrating the Challenges
10. Main Procedure • Create object instance • Store object • Load object SalesEmployee + Id : ObjectId + Name : String + Value : Int32 Mongo DB
12. db.GetCollection(''Employee'').Save(employee); Won’t build without MongoDB Reference
13. Won’t build without MongoDB Reference
14. Hands on case: Storing employees in a database Take 2 ”ActiveRecord Pattern”
15. Main Procedure • Create object instance • Store object • Load object SalesEmployee + Id : ObjectId + Name : String + Value : Int32 + Save() + Load() Mongo DB Active Record I
16. Main Procedure • Create object instance • Store object • Load object PersistentObject<T> + ObjectId + void Save(T obj) + T Load(ObjectId id) SalesEmployee + Name : String + Value : Int32 Mongo DB DataAccess Domain Active Record II
18. Hands on case: Storing employees in a database Take 3 ”Repository Pattern”
19. Main Procedure • Create object instance • Store object • Load object Employee + Name : String + Value : Int32 Repository<T> + void Save(T obj) + T Load(ObjectId id) IRepository<T> + Load() + Save() Sales Employee Developer Mongo DB DataAccess Domain Repository Pattern PersistentObject<T> + ObjectId
21. Hands on case: Storing employees in a database Take 4 ”DataMapper pattern”
22. Main Procedure • Map Data • Create object instance • Store object • Load object Employee + Id : String + Name : String + Value : Int32 Repository<T> + void Save(T obj) + T Load(String id) IRepository<T> + Load() + Save() Sales Employee Developer Mongo DB DataAccess Domain Settings + SetupDatabase() DataMapping DataMapper
24. Hands on case: Storing employees in a database Take 5 ”DataMapper pattern II”
25. Main Procedure • Create object instance • Store object • Load object Employee + Id : String + Name : String + Value : Int32 Repository<T> + void Save(T obj) + T Load(String id) Employee Repository IRepository<T> + Load() + Save() Sales Employee Developer +BestFriend : Developer Developer Repository Developer Repository Mongo DB DataAccess Domain DataMapper Pattern