Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as not constructive by Yannis Rizos Jun 12 '12 at 16:40

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Great question. I'm an MVC developer and am keen to know the answer to this. –  StuperUser Feb 14 '11 at 16:30
13  
These types of questions are open ended and are better answered by trolling the web IMHO. What can a BMW 335 do that a Hyundai Sonata can't? They both have 4 tries, a steering wheel and are built on the same consumption framework; fuel. These questions surface due to a lack of research on understanding on the given topics which can facilitate a more direct question....I'm sure many will disagree since this is programmers... –  Aaron McIver Feb 14 '11 at 17:26
1  
@Aaron - Even though I went through the trouble of adding an answer to this question, I agree with you in principle, and I hope that I made it clear that to borrow your analog, we are comparing one car to another. –  Adam Crossland Feb 14 '11 at 17:45
7  
I personally thought it was a valid question. Such questions should not be shot down so readily because a lot of us only know one side of the story and it helps to get an idea of the other side as well. BTW, asking a question on StackExchange qualifies as research in my book. –  Umar Farooq Khawaja Jun 6 '11 at 10:01
3  
I ask questions like this often and have them shot down, so I'd like to show some support here for the OP. Decisions taken when coding are almost always subjective. My right could be your wrong while both could develop working solutions of equal (subjective) merit. In this case the OP wants opinions on the relative merits of two opposing technologies. You won't find that information anywhere except in the minds of those who have been through the practical process of choosing one over the other. It is therefore a legitimate question. –  Ian Mar 4 '12 at 20:05
show 1 more comment

7 Answers

up vote 23 down vote accepted

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.

share|improve this answer
5  
Regarding the action parameters: I would have thought that public ActionResult Edit(Foothing foothing), i.e. the ModelBinder features were even neater. –  rmac May 7 '11 at 19:08
8  
The rails examples are pretty out of date. They work, but there are better ways to do this. –  Jason w May 11 '11 at 15:05
1  
@Jason: would you care to expand on this and maybe post a gist? –  Dan Feb 23 '12 at 8:44
1  
I agree that the request.post? looks unusual to me as well (maybe because it was used in older versions). I started with Rails 3 and the edit method is always a 'get'. I suppose you could configure it to be a post, but Rails uses a RESTful pattern that would use an 'update' method to do the post to any changes that would occur in a model. So, if done correctly you shouldn't even have to check if the 'edit' method was a post. –  PhillipKregg Mar 14 '12 at 17:08
1  
Voting you up simply because you present a sensible argument. I prefer Rails, but it's entirely subjective and you argue your case well. –  Stephen Orr May 30 '12 at 18:44
show 1 more comment

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.

share|improve this answer
6  
Ruby's ActiveRecord does allow you to eliminate a lot of code if you follow certain conventions, but it's not required. If the conventions aren't followed, then you have to be more explicit. –  kevin cline May 11 '11 at 14:40
add comment

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.

share|improve this answer
    
The Ruby language is strongly typed as well (also duck typed). And Rails uses active record to automatically associate its models with its views. You wouldn't need to declare them in the controller. If you wanted to create a nested hierarchy of views, you would create an instance variable in the controller representing the models that you would like to be passed to the view. So yes, they can both do the same thing. –  PhillipKregg Mar 14 '12 at 17:30
add comment

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.

share|improve this answer
1  
True - but Rails has also been around for about 8 years so it has a head start. I am coming from Rails to asp.net and MVC 3 is actually very nice. The Entity Framework and the NuGet package manager have been very impressive to me so far. –  PhillipKregg Mar 14 '12 at 17:34
add comment

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)

share|improve this answer
1  
Entity Framework 5.0 Code First supports Migrations –  hofnarwillie Oct 25 '13 at 10:39
    
Actually, code first migrations have been supported since 4.1, which was AFAIK released not too long after my edit. –  Pete Oct 25 '13 at 14:36
add comment

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.

share|improve this answer
6  
-1 I don't see any reason why ASP.NET MVC would be considered more flexible - if you look at the major components, routing, controllers, rendering, they are all just rips off rails and missing a lot of features, too. –  scottschulthess Mar 4 '12 at 19:51
    
How is asp.net mvc 'more open'? I can skip the whole crud scaffolding thing, and make my models and controllers from scratch plus create nested associations - one to many, many to one, many to many - without any 'break down'. And, if I decide to use a javascript heavy front-end, I can just as easily send all my model data to the client in JSON (or XML, or any other format). Plus, if you can think of a functionality that you would like to implement, than there's probably already a gem for that. It's not hard to find non-trivial Rails apps. –  PhillipKregg Mar 14 '12 at 17:45
1  
Being able to drop down to raw c# / .net framework could be considered more flexible? –  Chris Barry Mar 29 '12 at 11:28
add comment

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]

share|improve this answer
7  
You don't need a foreign key property on your entity framework objects. Also, EF is a completely separate product and is not integrated with ASP.NET MVC in any way. You should be using view models to construct your user interface and build any drop down lists or other controls. –  Lucifer Sam May 30 '12 at 14:49
    
I agree. You shouldn't have any ID keys at all in your entity frameworks. An ORM should handle object identity. But point taken; I'm really complaining more about the terrible EF ORM. That example is a simplified version coming directly from Microsoft by the way. That's exactly how they do it in their ContosoUniversity example. This does speak to my point. Microsoft doesn't know how to do MVC or ORM and their examples show it. –  Mike Bethany May 31 '12 at 17:46
    
Adding the ColorID property allows you to implement lazy loading patterns which is very useful at times. For example, if the referenced object is very large and you don't really need all the property values of the object, then it would be a waste of processing time to fetch it all just to find the associated ID part of it (ColorID). It also allows you to implement Nullable/Non-Nullable foreign keys, i.e. what if Color is not always needed? Change the ColorID to a Nullable Integer int? –  hofnarwillie Oct 25 '13 at 10:34
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.