O que o ASP.NET MVC pode fazer e o Ruby on Rails não pode? [fechadas]

O ASP.NET MVC e o Rails têm área de uso semelhante, são construídos em torno da mesma arquitetura, ambas as estruturas são relativamente novas e de código aberto.

Então, como programador do Rails, eu gostaria de saber, o que o ASP.NET MVC pode fazer e o Ruby on Rails não pode, e vice-versa?

Desenvolvi aplicativos reais com o Rails e o ASP.NET MVC, mas essa resposta vem com uma ressalva significativa: eu aprendi e desenvolvi com o Rails pré-versão 2, portanto, é perfeitamente possível que eu esteja desatualizado com o meu Trilhos de conhecimento.

Dito isto, não acho que exista algo que possa ser feito com um, mas não com o outro. Dado qualquer conjunto de requisitos para um aplicativo Web, você deve poder criar esse aplicativo - provavelmente de maneira igualmente eficiente - com o Rails ou o ASP.NET MVC.

Existem algumas coisas interessantes que - até onde eu sei - estão disponíveis no ASP.NET MVC, principalmente por causa dos aspectos do C # / .NET. Por exemplo: quando tenho uma página que contém um formulário enviado, eu teria uma Ação que verifica se está lidando com um GET ou um POST para decidir o que fazer:

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

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

Este é um exemplo trivial, mas o if request.post?padrão é extremamente comum no Rails. Para casos não triviais, o código de Ação pode ficar grande e confuso e, muitas vezes, eu gostaria de refatorá-lo em métodos separados de forma limpa. No ASP.NET MVC, posso fazer isso:

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

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

Eu acho que ser capaz de separar de maneira limpa o tratamento de solicitações GET e POST é legal. Sua milhagem pode variar.

A outra coisa que o ASP.NET MVC faz que é super legal (novamente na minha opinião) também está relacionada ao tratamento do formulário POSTS. No Rails, eu tenho que consultar o paramshash para todas as minhas variáveis ​​de formulário. Digamos que eu tenho um formulário com os campos 'status', 'gonkulated', 'invert' e 'disposion':

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

Mas o ASP.NET MVC permite que eu obtenha todos os meus valores de formulário como parâmetros para o meu método Action:

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

Essas são as duas coisas que eu realmente amei no ASP.NET MVC ou Rails. Eles não são uma razão suficiente para qualquer desenvolvedor sensato ou competente escolher uma estrutura sobre a outra.

Uma vantagem do ASP.NET MVC sobre Rails é se você precisar criar um novo aplicativo em um banco de dados existente. O ActiveRecord do Rails é muito opinativo sobre como as tabelas devem ser estruturadas (a tabela precisa ter uma e apenas uma coluna inteira como chave primária chamada 'id' etc.). Portanto, se suas tabelas existentes não estiverem em conformidade com as preferências do ActiveRecord, é difícil criar o ActiveRecord trabalhos. Mas o desenvolvimento de um novo aplicativo com o novo banco de dados com ActiveRecord e Rails é rápido!

O ASP.NET MVC não possui o ORM padrão. Você pode escolher uma estratégia de acesso a dados que atenda às suas necessidades. Alguns ORM como o nhibernate podem suportar bancos de dados herdados. Você pode ter chave primária guid, etc.

Existe uma alternativa ao Rails ActiveRecord chamada DataMapper , mas eu não tentei.

Tendo usado os dois, a resposta da IMO é que o ASP.NET MVC é mais flexível que o Rails se seu aplicativo precisar fazer mais do que apenas ler / gravar em um banco de dados. Na minha experiência, o Rails se decompõe rapidamente e intensamente no minuto em que você introduz qualquer tipo de complexidade ou lógica no aplicativo, além da lógica CRUD muito trivial. O ASP.NET MVC não encontra essa restrição, pois é mais "aberto" sobre o que você pode fazer.

Tudo o resto é igual em um aplicativo CRUD "Web 2.0" típico, não há nada que se possa fazer sobre o outro, mas para um aplicativo mais complicado que precisa de um fluxo de trabalho ou fontes de dados diferentes, ou para interagir com outro aplicativo ou qualquer outra coisa como CRUD não é típico, o ASP.NET pode fazer muito mais e não ser tão restritivo quanto o Rails.

Eu nunca trabalhei com Ruby on Rails, então não estou exatamente qualificado para responder a essa pergunta, mas uma coisa que eu gosto imensamente no ASP.NET MVC é a segurança de tipo. Isso vem no caminho. Adam Crossland e rmac abordaram brevemente isso em seus comentários, mas eu gostaria de salientar que, com um método de controle como o seguinte, cada um dos parâmetros será fortemente digitado. Isso torna o código no método Edit muito mais limpo, pois você não precisa se preocupar em converter representações de string em variáveis ​​digitadas corretamente.

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

O outro local em que essa segurança de tipo aparece é em Vistas e Vista Parcial, onde é possível associar uma vista de vista parcial a um objeto C # Antigo Simples, que servirá como modelo dessa Vista ou Vista Parcial. Isso facilita muito a vida, especialmente onde você deseja criar uma hierarquia de visualizações que contenham outras visualizações.

Se Infinity.ViewModels.Siteo namespace contiver uma classe chamada ContactViewModel, então, para as visualizações do Razor, faça-o colocando uma linha como esta no topo da visualização:

@model Infinity.ViewModels.Site.ContactViewModel

e para visualizações ASPX, faça-o declarando a visualização desta maneira:

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

Você associa a instância real do objeto de modelo à visualização no método de ação Controller e, em seguida, acessa a instância do objeto de modelo na visualização pela Modelpropriedade da visualização.

Esse tipo de força, para mim, é super legal. A equipe que criou o ASP.NET MVC se esforçou muito para fazer com que cada uma das 3 áreas de Modelo, Visualização e Controlador fosse fortemente digitada.

Não tenho certeza se o Ruby-on-Rails tem isso, mas espero que sim.

Eles são muito parecidos, e todos podem "fazer as mesmas coisas" principalmente, apenas algumas coisas são mais fáceis em uma e mais difíceis que outras.

Eu usei o ASP.NET MVC na versão original e foi definitivamente um clone do Rails menos o registro ativo. Portanto, o Rails quase certamente tem um conjunto de recursos muito maior e um ecossistema de plugins / gemas muito maior.

Na minha experiência limitada, a principal vantagem do ASP.NET MVC é que é uma linguagem compilada. Isso permite que você detecte alguns erros de programação já em compilação, nos quais o Ruby deve confiar na detecção e durante o teste de unidade.

Além disso, o fato de ser compilado torna possível ter ferramentas avançadas de refatoração, por exemplo, alterar o nome de uma propriedade em um único local, e todas as referências à propriedade são alteradas. Isso pelo menos não pode ser feito no TextMate, que muitos desenvolvedores do Rails usam.

Por outro lado, a principal vantagem do Ruby on Rails é que é uma linguagem interpretada. confira o livro Eloquent Ruby para alguns exemplos. E grande parte da própria estrutura do Rails se baseia nessa capacidade.

A capacidade de substituir qualquer método em qualquer objeto a qualquer momento também me ajudou muito na criação de testes de unidade. No .NET, os contêineres de Injeção de Dependência e IOC são praticamente requisitos para a criação de código testável. Isso não é necessário em Ruby.

Editar:

Depois de pensar sobre isso, provavelmente o recurso matador do Rails é a migração de banco de dados. A estrutura do ASP.NET MVC por si só não fornece nenhum suporte ao banco de dados. A estrutura .NET possui alguns componentes de acesso a dados / ORM, por exemplo, Entity Framework e Linq to Sql. Mas ele não possui nenhuma ferramenta para projetar a estrutura do banco de dados.

Se você pagar por uma das versões mais caras do VS, poderá obter o Data Dude , que permite projetar um esquema de banco de dados, e ter algumas ferramentas para implantar o esquema em um banco de dados. Mas, até onde sei, o suporte para lidar com migrações de versões anteriores do aplicativo é muito limitado.

Alguns afirmam que o ASP.NET MVC não é realmente uma estrutura MVC, apenas uma estrutura VC, devido à falta de suporte à migração de banco de dados.

Editar (novamente):

Alterações na cadeia de ferramentas do Visual Studio / EF introduziram migrações baseadas em código desde a minha última edição. (mas também confira o FluentMigrator se estiver seguindo esse caminho)

Meu maior problema com o MVC 3 e o Entity Framework da Microsoft são seus princípios de design incrivelmente ruins.

Um dos primeiros problemas que encontrei foi ao usar outra classe como uma propriedade e tentar criar uma lista suspensa para os possíveis valores.

Para ilustrar meu argumento, diga que você tem duas classes de modelo como esta:

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; }
}

Criar a propriedade Color seria suficiente para um ORM real, mas não para EF. Você precisa adicionar um ID redundante para a propriedade Color na classe Thing da seguinte maneira:

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

Se você não adicionar o campo ID redundante a uma referência a objeto externo, não poderá criar facilmente listas suspensas com todas as opções possíveis da classe vinculada.

Esse design é realmente terrível, pois combina fortemente o funcionamento interno de uma classe com a outra. A coisa não deve saber nada sobre ColorID, a classe Color deve manipular suas próprias verificações de igualdade sem expor que possui um ID.

Essas são as práticas recomendadas, mas aparentemente a Microsoft não tem conhecimento dos princípios básicos da ciência da computação e da programação orientada a objetos.