Friday, June 15, 2012

Grails 2.0 vs ASP.NET MVC 4 (Conclusion)


Background
This is the conclusion to two previous posts that considered the pros and cons of using Grails 2.0 vs ASP.NET MVC 4 for open source projects.  I have used both technologies for a few years apiece.  However, their latest incarnations have offered benefits over their respective predecessors.  Therefore, it was due time for me to reevaluate.


If you read my last post on this topic, ScrumTime - Grails 2.0 vs ASP.NET MVC 4, you saw that I came up with seven questions to use for the comparison.  I answered each question to the best of my ability at the time.  Since that post, I have researched both frameworks with two different open source projects: ScrumTime and BumbleBee.


ScrumTime source code on GitHub:
BumbleBee source code on GitHub:
If you are bored and actually want to view the source of all four projects, you will notice that the project with the most active work is the BumbleBee Grails 2 implementation.


What is BumbleBee?
BumbleBee allows project managers to track the progress of large software integration projects.  It provides a single view of Mantis bugs, test scripts, unit tests, design documents, and third party vendor issues.  The default security is currently single-sign on with active directory.  The SSO with AD is a post all its own since it is implemented in a java web stack.


What happened to ScrumTime?
I have only put ScrumTime to the side for the moment because I have a business "need" for the BumbleBee application immediately.  It seemed like an excellent candidate to finish my evaluation of Grails vs MVC.


What is the final web-stack decision and why?










I decided to complete the BumbleBee project in Grails 2.0 because of many factors:

  • velocity of implementation is quicker for me due to less source code and the following
    • repository finders are dynamically generated automatically (MVC does not have this)
    • pre-request, post-request, and post-view filters are much simpler to implement than MVC.
    • the default in-memory database supports live changes to the domain models without a server restart (MVC does not have this)
    • nearly all aspects of the web application can be changed without requiring a server restart (MVC has limited support for this)
  • the end result is a war file that will run on any hardware that can run jdk 6+ (MVC can only run on windows based computers (Mono would require significant EF changes)
  • more database vendor options after the product is developed
    • Because Grails is based on Gorm which is built on Hibernate, changing the back-end database vendor after the entire application is complete does not pose a challenge.  This can be done by changing the properties in the DataSource.groovy file.  However, the story with MVC is pretty bad.  The only options in MVC are to use nHibernate or create your own ORM from scratch.  Even in these cases, there is no automatic integration between the model objects of the MVC application based on nHibernate as there is with model objects based on the Entity Framework.  I can only guess that Microsoft prefers to make it easy for developers to connect to their own databases and not so easy to connect to other vendor databases.
These factors were too important to the success of an open source project for me to ignore.  

I hope to complete the first release of BumbleBee within the next few weeks.