ASP.NET vs Ruby on Rails : Round 3 (Object-Relational Modeling)

Before I start running down the bullet list, I feel as though I should point out that the ADO.NET Entity Framework and LINQ to Entities are still in CTP status - they are not beta, they are not RC, they are not released. There is still plenty of chance for the ADO.NET EF to radically change in ways that might affect the opinions and facts listed in this article. As such, this article is a comparison of how things stand on October 9th, 2006 :)

• Multiple Data Environments - As mentioned in previous articles, Rails provides the ability to have multiple data environments out of the box. It isn't very difficult to tweak the connection string for the mapping model in the EF. The difference arises in Rails use of fixtures which define how the test data for a given environment will look, allowing the code to pre-load the database with data that drives test cases. That said, I personally test my applications against snapshots of production data, having found that simulated data often rarely illuminates the unknown edge cases that occur in production data. I say this bullet point is a draw.
• Entity Composition - both  ActiveRecord and the ADOEF allow me to create a business object that has properties that are fed by multiple different underlying tables. For example, I can create an Employee class that has a FirstName and a LastName property. The FirstName and LastName properties could actually be fed by an EmployeeNames table. This feature is also a draw since both have it.
• Entity Inheritance - Both ActiveRecord and ADOEF allow me to create an entity type called VideoGames and one called WiiGames, and have WiiGames be conditional such that you can identify a disciminator column that will identify which rows in the VideoGames table produce a class instance of type WiiGames and which produce a class instance of type Ps3Game, etc. In addition, you can have the host table provide nullable columns that will have data when applied to child types. For example, you could have a property on the WiiGame type called UsesNunchaku that only appears on class instances of the type WiiGame, all others don't have that property. This bullet point is also a draw.
  
• Caveat: You cannot have a discriminator column on a foreign key column!!! This applies to BOTH ActiveRecord AND ADOEF. This means that if you are using a number in the GameType column that points to the ID in the GameTypes table ... and you're using that same number as the discriminator column, both systems will fail. This is a huge pain in the ass, personally, but it makes sense after a few hours of poring over the internals of how the systems are implemented.
• Filtering and Querying - both systems allow for filters and queries to be used. Both systems support the use of lambda functions to provide embedded, inline code blocks that can be passed to filter functions for limiting the data. However, I happen to be a huge fan of LINQ and I still think that the LINQ to Entities syntax can be cleaner at times than the ActiveRecord syntax. I would have to give this bullet point to the ADOEF.
• Performance - I have no real comparison on performance. Against the same 2,500 row table with associated child tables, both ActiveRecord and ADOEF churned through the data so that I saw no visible difference in performance. Given that ADOEF uses a native SQL driver and ActiveRecord uses OLE automation to communicate with SQL, I would have to give the performance category to ADOEF when communicating with SQL Server 2005. I have absolutely no data on which one performs better against Oracle, mySQL, etc.
• Visual Designer - this is kind of a cheap category.. but I needed to throw it in. When it ships, ADOEF will have a visual designer for laying out the entity model and mapping the entities to the underlying schema, etc. This will be really nice and handy, but I don't think it will dramatically increase the productivity of the ADO.NET programmer over the Rails programmer.

Overall, I have to admit that I was incredibly surprised by the power and flexibility of ActiveRecord. I came into this round thinking that ActiveRecord was going to be the clearly inferior product. As both products stand right now, ADOEF and ActiveRecord are both really good tools. I think the ADO.NET Entity Framework comes out ahead in many respects and the real winner is subjective. ADO.NET EF clearly favors configuration over convention because each entity model is actually three fairly large XML files that, without the visual designer, would be a huge pain in the butt to modify (note that I'm currently modifying them by hand during this CTP anyway...).

So - do you want the (in my opinion) extremely elegant syntax provided by LINQ to Entities, or do you want the somewhat more "SQLish" syntax of ActiveRecord filters? One comes with the (soon to be negated) overhead of 3 XML files while the other defines many of the definition shortcuts directly in the model .rb files - something many ORM purists dislike. There is a huge argument as to whether the model should define the mapping, or whether the mapping should be external to the model, leaving the model as a pure model... I often tend to lean toward the latter, thinking that the model should be just that - a pure model with no knowlege whatsoever of its entity persistence mechanism.

So, in conclusion, what I think I will be doing from now on is taking the lessons learned from writing Ruby on Rails applications and the patterns that it enforces so rigidly, and turn that into prescriptive guidance for building ASP.NET applications using the ADO.NET Entity Framework. ASP.NET is flexible enough that I can rip out large portions of it and replace the gutted remains with some very MVC-ish style application frameworks. The initial work of gutting and replacing might take more time than building a Ruby on Rails app, but once done, that new application building block can be reused over and over again. I think of it as the best of both worlds - the bent toward simplicity and the huge benefits of the MVC pattern exhibited by Ruby on Rails, with the enterprise features built into ASP.NET and the (slightly) more robust features of the ADO.NET Entity Framework.

Bottom line is you should pick whats best for you. Ruby on Rails solves a lot of problems more quickly and easily than ASP.NET does, whereas ASP.NET has a lot of features built in that you need additional gems and code generators for in Ruby. The real truth is that I see that Ruby on Rails and ASP.NET solve two different types of web application problems...and where they overlap, you can take Ruby design patterns and implement in them in ASP.NET for a "best of both worlds" approach.

tags: ruby  rails  asp  aspnet  aspnet  adonet  net  framework  web  entity  entityframework  adoef  linq  dlinq  elinq  

links: digg this    del.icio.us    technorati    reddit