Thoughts on MongoDB
I just recently posted a short write up on Fluent NHibernate vs. Code First in Enterprise Library 4.1.
I’m starting up a new pet project (or rather re-starting it after a 3 year hiatus) so I’ve been trying to figure out the underlying technologies that I want to build on (as I mentioned, I’ve been in the SharePoint space for so long now, that I haven’t been up-to-date on the latest developments in DB storage). To be honest, I wasn’t really satisfied with the experience of either FNH or EF4.1, especially as I started to work with my model more and more.
What I realized is that the object-relational disconnect is still there. I’m starting to think that no amount of lipstick will make that pig presentable. It doesn’t make a whole lot of sense and is an impediment to productivity in today’s application-layer-oriented environment (if that makes any sense…); I really, really, really want to stop building database applications and focus my time and energy on the application layer.
Of course, one neat thing about the nature of working with JSON from UI to the database is that in some cases, the application layer can be relegated to a relatively dumb pass-through (seems like it’s still needed as one area of weakness for Mongo is authentication and authorization). Get your objects in JSON, bind to them in the browser using KO, modify them, and send them back! It’s a beautiful paradigm that could only be better with an out-of-the-box REST interface like CouchDB.
I’m just digging in, but I’m starting to think that I’m never going to look back at relational databases outside of client work and possibly as a supplementary data store for reporting purposes. It only takes a few moments to get started with Mongo so give it a shot!