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

36

ASP.NET MVC e Rails têm área de uso semelhante, são construídos em torno da mesma arquitetura, ambos os frameworks são relativamente novos e de código aberto.

Então, como um 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?

    
por Nikita Barsukov 14.02.2011 / 17:08
fonte

7 respostas

31
Eu desenvolvi aplicações reais com Rails e ASP.NET MVC, mas esta resposta vem com uma advertência significativa: eu aprendi e desenvolvi com Rails pré-versão 2, então é inteiramente possível que eu esteja totalmente fora de série. data com meu conhecimento Rails.

Dito isso, não acho que haja qualquer coisa que possa ser feito com um, mas não o outro. Dado qualquer conjunto de requisitos para um aplicativo da Web, você deve ser capaz de criar esse aplicativo - provavelmente de forma igualmente eficiente - com Rails ou ASP.NET MVC.

Existem algumas coisas interessantes que - até onde sei - estão disponíveis no ASP.NET MVC principalmente por causa de aspectos do C # / .NET. Por exemplo: quando eu tenho uma página que contém um formulário que é 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 padrão if request.post? é extremamente comum no Rails. Para casos não-triviais, o código de ação pode ficar grande e bagunçado e, muitas vezes, eu gostaria de poder refatorá-lo em métodos separados de forma limpa. No asp.net MVC eu 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 a ASP.NET MVC faz é super legal (novamente, na minha opinião) também está relacionada ao tratamento de formulários POSTS. No Rails, tenho que consultar o hash params para todas as minhas variáveis de formulário. Digamos que eu tenha 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 a ASP.NET MVC permite-me obter 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 motivo suficiente para qualquer desenvolvedor sensato ou competente escolher uma estrutura sobre a outra.

    
por 14.02.2011 / 18:43
fonte
6

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

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

Existe uma alternativa para o Rails ActiveRecord chamado DataMapper , mas eu não tentei.

    
por 11.05.2011 / 09:00
fonte
2
Tendo usado ambos, a resposta IMO é que o ASP.NET MVC é mais flexível do que o Rails se seu aplicativo precisar fazer mais do que apenas leitura / gravação em um banco de dados. Na minha experiência, o Rails quebra rapidamente e intensamente no momento em que você introduz qualquer tipo de complexidade ou lógica na aplicação além da lógica CRUD muito trivial. O ASP.NET MVC não encontra essa restrição, já que é mais "aberto" sobre o que você pode fazer.

Tudo o mais sendo igual em um aplicativo CRUD típico "Web 2.0" 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 coisa que não seja típica do CRUD, o ASP.NET pode fazer muito mais e não ser tão restritivo quanto o Rails.

    
por 11.05.2011 / 16:21
fonte
2

Eu nunca trabalhei com Ruby on Rails, então eu não sou exatamente qualificado para responder a essa pergunta, mas uma coisa que eu gosto muito sobre a ASP.NET MVC é a segurança de tipos. Isso vem em caminho. Adam Crossland e rmac falaram brevemente sobre isso em seus comentários, mas eu gostaria de salientar que com um método controlador como o seguinte, cada parâmetro será strongmente tipado. Isso torna o código dentro do método Edit muito mais limpo, pois você não precisa se preocupar com a conversão de representações de strings em variáveis digitadas corretamente.

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

O outro local em que esse tipo de segurança é exibido é em Visualizações e Visão Parcial, onde é possível associar uma visão de visão parcial a um objeto Plain Old C #, que servirá como o modelo de Visualização ou Visão Parcial. Isso facilita muito a vida, especialmente quando você deseja criar uma hierarquia de visualizações que contenha outras visualizações.

Se Infinity.ViewModels.Site for o namespace que contém uma classe chamada ContactViewModel , então, para as visualizações do Razor, faça isso colocando uma linha como essa na parte superior da exibição:

@model Infinity.ViewModels.Site.ContactViewModel

e para exibições ASPX, você faz isso declarando a exibição dessa 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 à exibição no método de ação do Controlador e, em seguida, acessa a instância do objeto de modelo na exibição pela propriedade Model da exibição.

Essa strong tipagem, para mim, é super legal. A equipe que criou a ASP.NET MVC dedicou muito esforço para tornar cada uma das três áreas de modelo, visualização e controlador strongmente digitadas.

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

    
por 06.06.2011 / 12:20
fonte
1

Eles são muito parecidos, e todos podem "fazer as mesmas coisas" na maioria das vezes, apenas algumas coisas são mais fáceis em um e mais difíceis do que outras.

Eu usei o ASP.NET MVC em torno do lançamento original e foi definitivamente um clone do Rails menos o ativerecord. Então, o Rails quase certamente tem um conjunto de recursos muito maior e um ecossistema de plugin / gem muito maior.

    
por 04.03.2012 / 20:53
fonte
1

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

Além disso, o fato de que ele é compilado torna possível ter ferramentas avançadas de refatoração, por exemplo, mude o nome de uma propriedade em um lugar, e todas as referências à propriedade são mudadas. 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;) A natureza do Ruby, como você pode modificar qualquer objeto na memória, ou monkey patch uma classe, pode levar a algumas muito elegantes soluções; confira o livro Eloquent Ruby para alguns exemplos. E uma grande parte da estrutura do Rails baseia-se nessa habilidade.

A capacidade de substituir qualquer método em qualquer objeto a qualquer momento também me ajudou muito a escrever testes de unidade. No .NET, Dependency Injection e IOC containers são virtualmente 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 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 para Sql. Mas não possui ferramentas para projetar a estrutura do banco de dados.

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

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

Edite (de novo):

As alterações no conjunto de ferramentas do Visual Studio / EF introduziram migrações baseadas em código desde a minha última edição. (mas também verifique FluentMigrator se você está indo por esse caminho)

    
por 30.05.2012 / 16:46
fonte
-1

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 com que me deparei foi ao usar outra classe como propriedade e tentar criar uma lista suspensa para os valores possíveis.

Para ilustrar meu argumento, você tem duas classes de modelo assim:

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 forma:

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 de ID redundante a uma referência de objeto externo, não poderá criar facilmente listas suspensas com todas as opções possíveis da classe vinculada.

Este é um projeto realmente terrível, pois une strongmente o funcionamento interno de uma classe a outra. A coisa não deve saber nada sobre o ColorID, a classe Color deve lidar com suas próprias verificações de igualdade sem expor que ela tem um ID.

Esta é uma das melhores práticas, 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. [/ rant]

    
por 30.05.2012 / 15:22
fonte