What ASP.NET MVC can do and Ruby on Rails can't? [closed]

Question

ASP.NET MVC and Rails have similar area of use, are built around same architecture, both frameworks are relatively new and open source.

So as a Rails programmer I'd like to know, what ASP.NET MVC can do and Ruby on Rails can't, and visa versa?

Answer 1

I have developed real applications with both Rails and ASP.NET MVC, but this answer comes with a significant caveat: I learned and developed with pre-version 2 Rails, so it is entirely possible that I am vastly out-of-date with my Rails knowledge.

That being said, I don't think that there is anything that can be done with one but not the other. Given any set of requirements for a web application, you should be able to build that app -- probably equally efficiently -- with either Rails or ASP.NET MVC.

There are a couple of neat things that -- to the best of my knowledge -- are available in ASP.NET MVC mainly because of aspects of C#/.NET. For example: when I have a page that contains a form that is submitted, I would have an Action that checks to see if it is dealing with a GET or a POST to decide what to do:

def edit
  @item = Item.find(params[:id])

  if request.post? 
    @item.update_attributes(params[:item])
    redirect_to :action => 'edit', :id => @item.id 
  end
end

This is a trivial example of it, but the if request.post? pattern is an extremely common one in Rails. For non-trivial cases, the Action code can get big and messy, and often, I'd wish that I could refactor it into separate methods cleanly. In ASP.NET MVC I can do that:

public ActionResult Edit() {
  // Render my page that has the Edit form
  ...
}

[HttpPost]
public ActionResult Edit(Foothing foo) {
  // Save my Foothing data
  ...
}

I think that being able to cleanly separate the handling of GET and POST requests is neat. Your mileage may vary.

The other thing that ASP.NET MVC does that is super cool (again in my opinion) is also related to handling form POSTS. In Rails, I have to query the params hash for all of my form variables. Let's say that I have a form with the fields 'status', 'gonkulated', 'invert' and 'disposition':

def edit
  @item = Item.find(params[:id])

  if params[:status] == "new"
    ...
  else
    ...
  end

  if params[:gonkulated] == "true"
    ...
  else
    ...
  end

  if params[:invert] == "true"
    ...
  else
    ...
  end

  # Rest ommited for brevity
end

But ASP.NET MVC neatly allows me to get all of my form values as parameters to my Action method:

[HttpPost]
public ActionResult Edit(int id, string status, bool gonkulated, bool invert, int disposition) {
    ...
}

Those are the two things that I really loved about ASP.NET MVC or Rails. They are not enough of a reason for any sane or competent developer to choose one framework over the other.

Answer 2

One advantage of ASP.NET MVC over Rails is if you need to build a new application over an existing database. Rails' ActiveRecord is very opinionated about how tables should be structured (table has to have one and only one integer column as primary key called 'id', etc) so if your existing tables do not conform to ActiveRecord preferences, it's tough to make ActiveRecord work. But developing new app with new db with ActiveRecord and Rails is fast!

ASP.NET MVC doesn't have default ORM. You can choose a data access strategy that fits your need. Some ORM like nhibernate can support legacy databases. You can have guid primary key, etc.

There's an alternate to Rails ActiveRecord called DataMapper, but I haven't tried it.

Answer 3

Having used both, the answer IMO is that ASP.NET MVC is more flexible than Rails if your application needs to do more than just read/write from a database. In my experience Rails breaks down quickly and heavily the minute you introduce any kind of complexity or logic to the application beyond very trivial CRUD logic. ASP.NET MVC doesn't encounter this restriction since it's more "open" about what you can do.

All else being equal in a typical "Web 2.0" CRUD app there isn't anything one can do over the other, but for a more complicated application that needs a workflow, or disparate data sources, or to interact with another application, or anything that isn't typical CRUD, ASP.NET can do a lot more and not be as restrictive as Rails.

Answer 4

I have never worked with Ruby on Rails, so I am not exactly qualified to answer this question, but one thing I like about ASP.NET MVC immensely is the type-safety. This comes in way. Adam Crossland and rmac touched on it briefly in their comments, but I would like to point out that with a controller method like the following, each of the parameter will be strongly typed. This makes the code within the Edit method a lot cleaner in that you don't have to worry about converting string representations into properly typed variables.

[HttpPost]
public ActionResult Edit(int id, string status, bool gonkulated, bool invert, int disposition) {
    ...
}

The other place this type-safety shows up is in Views and Partial View where one can associate a view of partial view with a Plain Old C# object, which will serve as that View's or Partial View's model. This makes life a lot easier, especially where you want to build a hierarchy of views that contain other views.

If Infinity.ViewModels.Site is the namespace containing a class called ContactViewModel, then for Razor views, you do it by placing a line like this at the top of the view:

@model Infinity.ViewModels.Site.ContactViewModel

and for ASPX views, you do it by declaring the view this way:

<%@ Page Language="C#" ="~/Views/Shared/Site.master" ="System.Web.Mvc.ViewPage<Infinity.ViewModels.Site.ContactViewModel>" %>

You associate the actual instance of the model object with the view in the Controller action method and then access the instance of the model object in the view by the Model property of the view.

This strong-typed-ness, for me, is super-cool. The team that created ASP.NET MVC has spent a lot of effort to make each of the 3 Model, View and Controller areas strongly typed.

I am not sure if Ruby-on-Rails has this, but I would hope so.

Answer 5

They are very similar, and they can all "do the same things" mostly, just some things are easier in one and harder than other.

I used ASP.NET MVC around the original release and it was definitely a Rails clone minus activerecord. So, Rails almost certainly has a much larger featureset and a much larger plugin/gem ecosystem.

Answer 6

In my limited experience, the main advantage to ASP.NET MVC is that it is a compiled language. This allows you to detect some programming bugs already at compilation, where Ruby has to rely on detecting then during unit testing.

Also the fact that it is compiled makes it possible to have advanced refactoring tools, e.g. change the name of a property in one place, and all references to the property is changed. This at least cannot be done in TextMate, which many Rails developers use.

On the other hand, the main advantage of Ruby on Rails is that it is an interpreted language ;) The nature of Ruby, how you can modify any object in memory, or monkey patch a class, can lead to some very elegant solutions; check out the book Eloquent Ruby for some examples. And a great deal of the Rails framework itself is based on this ability.

The ability to replace any method at any object at any time has also helped me greatly in writing unit tests. In .NET, Dependency Injection and IOC containers are virtually requirements for creating testable code. That is not necessary in Ruby.

Edit:

After thinking about it, probably the killer feature of Rails is database migration. The ASP.NET MVC framework does not in itself provide any database support. The .NET framework does have some data access components/ORM, e.g. Entity Framework and Linq to Sql. But it does not have any tools for designing the database structure.

If you pay for one of the more expensive versions of VS, you can get the Data Dude, which lets you design a database schema, and have some tools for deploying the schema to a database. But as far as I can tell, support for handling migrations from earlier versions of the application is very limited.

Some claim that ASP.NET MVC is not really an MVC framework, merely a VC framework, due to the lack of support for database migration.

Edit (again):

Changes to the Visual Studio toolchain/EF have introduced code based migrations since my last edit. (but also check out FluentMigrator if you are going down that path)

Answer 7

My major problem with Microsoft's MVC 3 and Entity Framework are their staggeringly bad design principles.

One of the very first issues I ran into was when using another class as a property and trying to create a dropdown list for the possible values.

To illustrate my point say you have two model classes like this:

public class Color
{
    public int ID { get; set; }
    public string Name { get; set; }
}

public class Thing
{
    public int ID { get; set; }
    public string Name { get; set; }
    public virtual Color Color { get; set; }
}

Creating the Color property would be sufficient for a real ORM but not EF. You have to add a redundant ID for the Color property in the Thing class like so:

public class Thing
{
    public int ID { get; set; }
    public string Name { get; set; }
    public int ColorID { get; set; }
    public virtual Color Color { get; set; }
}

If you don't add the redundant ID field for a foreign object reference you can't easily create dropdown lists with all of the possible options from the linked class.

This is really terrible design as it strongly couples the internal workings of one class to another. Thing shouldn't know anything about ColorID, the Color class should handle its own equality checks without exposing that it even has an ID.

This is best practices 101 stuff but apparently Microsoft is totally unaware of basic principles of computer science and object oriented programming.[/rant]