Massive Effect

Hope you have read my earlier post about Micro ORM. Here I talk about another Micro ORM, Massive. I don't want to go with the traditional approach. I write an intro about Rob Conery and give some details about Massive. A few examples here and there, some hyperlinks and that's it. I will try to find the answer to "why" instead of "how". For the how part, we have more than enough examples and also have stackoverflow to solve issues. Still, I go through technical details at the end, but the article will not be like a tutorial for Massive.

Let's start from the start. I was just wandering around the asp.net website. And I came across the tutorial of store front. There I found a person with the name Rob Conery. As usual, I found his site and came to know that he recently left his job. I was a little upset, as I liked the way he explained things. Then I came across another video of his in the speaking section, Kill Your ORM. This is the first time I came across something called Micro ORM. And this is the moment when I pressed the refresh button on my technical skills, thinking, or approach—whatever you can say. I just opened up my mind to options I'm trying.

Rob Conery is like Tony Stark of the Technical Arena. And every now and then he creates some new element (OSS).

The second one in the white shirt is Rob Sir. He is not just in his Iron suit. And here are a few elements created by him: Massive, [Manatee][12], and [Sub Sonic][13].

And there are a few other heroes of mine, specifically in the technical arena. But I'll talk about them later. Still, you can enjoy the image comparison.

And

Images are of course not my proprietary. If anyone has a problem with it, please let me know and I will remove it.

Now, come back to Massive.

Why???????

Isn't it nice to have POCO objects that will take care of everything? Obviously it is NICE. I don't like databases at all. And those complex joins and yet another language to learn… Nope. I hate it. But just give me the answer to one simple question.

If I am using ORM, does it allow me to not use SQL at all?

No. I don't think so. And I'm not talking about a hypothetical situation. I'm talking about a real-life situation. Real projects and real experience. Every now and then I have to double-check my query with SQL. This just doubles my work. And it is useful only to add value to my resume. Here I'm not talking about performance at all. Everyone knows benchmarks. I'm talking about working on actual systems. In a very distributed system with DBAs working around the clock.

Is there a space for ORM?

No, I don't think so. If I am alone and working on a small-scale project, then it's fine. Just go with it. But with big-scale projects, even today, DBAs are an integral part of the system. And trust me, they don't know .net or Java or don't even care about it. I have used [IOC][18], [Repository Pattern][19], [Factory Pattern][20], or anything else—they don't even care. They just create those messy tables that no one is going to understand in one shot. At least I never understand those one-to-one and one-to-many and n-level-down table relationships in one shot. I remember them eventually, but still, no chance at first glance.

Many will argue that ORMs will decrease my work at the application level. Yes, maybe. But the thing is, I'm learning something to replace something. Like I'm learning Entity Framework because I don't like working with SQL. I learn every in and out of Entity Framework, checking out screencasts, blogs, articles, etc. And one day I have to debug a query that is SQL. I feel this is just overhead. At least for now. At some point in time, maybe there will be no need for databases or SQL. Everything will shift to the application level, and at that point, EF will be a necessity or just part of the language. But now it is not. And that is creating problems. And this is a general statement for all ORMs. You are learning something new, but the old is still there—you can't escape it. Even Massive has some learning curve. But in the case of Micro ORMs, the learning curve is somewhat simpler and smaller.

If in any case, Rob sir, if you are reading this article, can you please answer these questions? Should I devote more time to executing complex tasks, or why is an ORM not working to execute the task? Either learn and add an HTML tag, or give more time to why the HTML helper is not working?

Meaning, there are more important things to do than solving errors in frameworks that are designed to help us. I'm not criticizing frameworks—I just love them and can't live without them—but if they are replacing core functionality, then good. But if I have to use a combination, then I'm not in favor of it. Like C# is developed over C++, but I never have to debug C# at the C++ level. I hope you are getting my point. One more example is [knockoutjs][21]. It is a JavaScript library that uses the "data-bind" keyword to bind with JavaScript objects or functions. Now, I want to use it with an HTML helper. I simply pass an anonymous object and bang—an error arrives. I Google it, waste almost half an hour, and find out I have to pass "data_bind" instead of "data-bind" specifically for the helper method. If I were using pure HTML syntax, half an hour would be saved.

I'm not opposing the concept of ORM, and if I got the chance, I would work to improve it to the next level. But when I have to create an application with time constraints, I will avoid it. This is a completely personal opinion. But I do have some reasons to support my opinion.

Now, How?

As promised, this will be short and sweet. I personally go for the [MVVM pattern][22]. Now, if I'm developing an application using Asp.Net MVC, I have a controller, model, and view. Now, in the model section, I separate it into two sections: ViewModel and Model. I do this by using two different files. You can choose any other approach. In the model, we have a class that has a one-to-one relationship with the database and is inherited from DynamicModel from Massive. And the view model has a class that can be used in views, and the same type of class we can have in JavaScript. So, it can be used with [knockoutjs][21]. Here are some examples of Massive. This is directly taken from the site. If anyone wants, they can skip it.

This is another best part of Micro ORM. You don't need a tutorial at all. I'm not good at SQL, but Massive can execute any complex SQL using the same syntax. Massive itself is quite simple. So, I don't have anything special, complex, or alien to write.

public class Products:DynamicModel { //you don't have to specify the connection - Massive will use the first one it finds in your config 

public Products(): base ( "northwind" , "products" , "productid" ) { } } var table = new Products(); //grab all the products var products = table.All(); //just grab from category 4. This uses named parameters var productsFour = table.All(columns: "ProductName as Name" , where : "WHERE categoryID=@0" ,args: 4); var result = tbl.Query( "SELECT * FROM Categories" ); // my favorite function, no need to learn massive use this function :P for Grid view like things, it also has paged query. var result = tbl.Paged(where : "UnitPrice > 20" , currentPage:2, pageSize: 20); // Insert and update are quite flexible in Massive, you should try with different options var table = new Products(); var poopy = new {ProductName = "Chicken Fingers" }; //update Product with ProductID = 12 to have a ProductName of "Chicken Fingers" table.Update(poopy, 12); var table = new Products(); //update Product with ProductID = 12 to have a ProductName of whatever was submitted via the form table.Update(poopy, Request.Form); //pretend we have a class like Products but it's called Categories var table = new Categories(); //do it up - the new ID will be returned from the query var newID = table.Insert(new {CategoryName = "Buck Fify Stuff" , Description = "Things I like" });

So, here is the reason why I prefer Micro ORM or NO ORM over ORM. I learned, I used, and I got hurt, so I avoid it. But trust me, ORM is so cool to mess with, but it should be done in free time for personal learning, at least for now. Still, there can be a few more things to discuss, but I'd like to do that in the comment section, specially for this article.

Comments are always welcome!!!

[]: https://lh5.googleusercontent.com/-Eq-pGJZhHtU/URHJx47Y2dI/AAAAAAAAAsY/LO2BqVFZUTQ/s800/iron-man-32_2.jpg []: https://lh6.googleusercontent.com/-GIE2x98SNDE/URHJqwsNwNI/AAAAAAAAAqM/l7n__dsAo9o/s800/RobCon_Hanselman_2_2.jpg [12]: http://github.com/robconery/manatee [13]: http://github.com/robconery/subsonic []: https://lh5.googleusercontent.com/-xtkof-Bai6g/URHJqhgda7I/AAAAAAAAAqE/CqRSsiZ424k/s800/Qui_gon_jinn_from_movie_2.jpg []: https://lh3.googleusercontent.com/-jzEvsjhnylg/URHJuutPtOI/AAAAAAAAArY/wmXiv7qRjEg/s800/hanselman_4.png []: https://lh4.googleusercontent.com/-2FeVrSh4Xas/URHJnpRUhnI/AAAAAAAAAo8/dvptH8qu1qY/s800/149117-batman-returns-dos-screenshot-main-computer-s_2.gif []: https://lh4.googleusercontent.com/-uTs5lIhQLgA/URHJz2abyDI/AAAAAAAAAs4/agORU4lbeoo/s800/phil_2.jpg [18]: http://en.wikipedia.org/wiki/Inversion_of_control [19]: http://www.martinfowler.com/eaaCatalog/repository.html [20]: http://www.oodesign.com/factory-pattern.html [21]: http://knockoutjs.com/ [22]: http://en.wikipedia.org/wiki/MVVM