¿Qué puede hacer ASP.NET MVC y Ruby on Rails no? [cerrado]

ASP.NET MVC y Rails tienen un área de uso similar, están construidos alrededor de la misma arquitectura, ambos marcos son relativamente nuevos y de código abierto.

Entonces, como programador de Rails, me gustaría saber qué puede hacer ASP.NET MVC y Ruby on Rails, y viceversa.

He desarrollado aplicaciones reales con Rails y ASP.NET MVC, pero esta respuesta viene con una advertencia importante: aprendí y desarrollé con Rails anteriores a la versión 2, por lo que es muy posible que esté muy desactualizado con mi Rieles de conocimiento.

Dicho esto, no creo que no hay nada que se pueda hacer con uno pero no el otro. Dado cualquier conjunto de requisitos para una aplicación web, debería poder construir esa aplicación, probablemente de manera igualmente eficiente, con Rails o ASP.NET MVC.

Hay un par de cosas interesantes que, que yo sepa, están disponibles en ASP.NET MVC principalmente debido a aspectos de C # /. NET. Por ejemplo: cuando tengo una página que contiene un formulario que se envía, tendría una Acción que verifica si se trata de un GET o un POST para decidir qué hacer:

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 es un ejemplo trivial, pero el if request.post?patrón es extremadamente común en Rails. Para casos no triviales, el código de acción puede volverse grande y desordenado y, a menudo, desearía poder refactorizarlo en métodos separados limpiamente. En ASP.NET MVC puedo hacer eso:

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

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

Creo que es capaz de separar limpiamente el manejo de las solicitudes GET y POST. Su experiencia puede ser diferente.

La otra cosa que ASP.NET MVC hace que es súper genial (nuevamente en mi opinión) también está relacionada con el manejo de POSTS de formulario. En Rails, tengo que consultar el paramshash para todas mis variables de formulario. Digamos que tengo un formulario con los campos 'estado', 'gonkulated', 'invert' y '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

Pero ASP.NET MVC me permite obtener todos mis valores de formulario como parámetros para mi método de acción:

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

Esas son las dos cosas que realmente me encantaron de ASP.NET MVC o Rails. No son razón suficiente para que un desarrollador cuerdo o competente elija un marco sobre el otro.

Una ventaja de ASP.NET MVC sobre Rails es si necesita crear una nueva aplicación sobre una base de datos existente. ActiveRecord de Rails es muy obstinado acerca de cómo deben estructurarse las tablas (la tabla debe tener una y solo una columna entera como clave principal llamada 'id', etc.), por lo que si sus tablas existentes no se ajustan a las preferencias de ActiveRecord, es difícil hacer ActiveRecord trabajo. ¡Pero desarrollar una nueva aplicación con nueva base de datos con ActiveRecord y Rails es rápido!

ASP.NET MVC no tiene ORM predeterminado. Puede elegir una estrategia de acceso a datos que se ajuste a sus necesidades. Algunos ORM como nhibernate pueden soportar bases de datos heredadas. Puede tener clave primaria guid, etc.

Hay una alternativa a Rails ActiveRecord llamada DataMapper , pero no lo he probado.

Después de haber usado ambos, la respuesta IMO es que ASP.NET MVC es más flexible que Rails si su aplicación necesita hacer más que solo leer / escribir desde una base de datos. En mi experiencia, Rails se descompone rápidamente y fuertemente en el momento en que introduce cualquier tipo de complejidad o lógica a la aplicación más allá de la lógica CRUD muy trivial. ASP.NET MVC no encuentra esta restricción ya que es más "abierto" sobre lo que puede hacer.

En igualdad de condiciones en una aplicación CRUD "Web 2.0" típica, no hay nada que uno pueda hacer sobre el otro, sino una aplicación más complicada que necesita un flujo de trabajo o fuentes de datos dispares, o para interactuar con otra aplicación, o cualquier otra cosa. eso no es CRUD típico, ASP.NET puede hacer mucho más y no ser tan restrictivo como Rails.

Nunca he trabajado con Ruby on Rails, por lo que no estoy exactamente calificado para responder a esta pregunta, pero una cosa que me gusta de ASP.NET MVC es la seguridad de los tipos. Esto viene en camino. Adam Crossland y rmac lo mencionaron brevemente en sus comentarios, pero me gustaría señalar que con un método de controlador como el siguiente, cada uno de los parámetros estará fuertemente tipado. Esto hace que el código dentro del método Edit sea mucho más limpio, ya que no tiene que preocuparse por convertir las representaciones de cadenas en variables escritas correctamente.

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

El otro lugar donde se muestra este tipo de seguridad es en Vistas y Vista parcial, donde se puede asociar una vista de vista parcial con un objeto C # antiguo sin formato, que servirá como modelo de esa Vista o Vista parcial. Esto hace la vida mucho más fácil, especialmente donde desea construir una jerarquía de vistas que contienen otras vistas.

Si se Infinity.ViewModels.Sitellama el espacio de nombres que contiene una clase ContactViewModel, entonces para las vistas Razor, lo hace colocando una línea como esta en la parte superior de la vista:

@model Infinity.ViewModels.Site.ContactViewModel

y para las vistas ASPX, lo hace declarando la vista de esta manera:

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

Asocia la instancia real del objeto modelo con la vista en el método de acción Controlador y luego accede a la instancia del objeto modelo en la vista por la Modelpropiedad de la vista.

Este tipo fuerte, para mí, es súper genial. El equipo que creó ASP.NET MVC ha realizado un gran esfuerzo para hacer que cada una de las 3 áreas de Modelo, Vista y Controlador esté fuertemente tipada.

No estoy seguro de si Ruby-on-Rails tiene esto, pero espero que sí.

Son muy similares, y todos pueden "hacer lo mismo" principalmente, solo algunas cosas son más fáciles en una y más difíciles que otras.

Utilicé ASP.NET MVC alrededor del lanzamiento original y definitivamente fue un clon de Rails menos el registro activo. Por lo tanto, Rails casi seguramente tiene un conjunto de características mucho más grande y un ecosistema de complementos / gemas mucho más grande.

En mi experiencia limitada, la principal ventaja de ASP.NET MVC es que es un lenguaje compilado. Esto le permite detectar algunos errores de programación ya en la compilación, donde Ruby tiene que confiar en detectarlos durante las pruebas unitarias.

Además, el hecho de que se compila permite tener herramientas de refactorización avanzadas, por ejemplo, cambiar el nombre de una propiedad en un lugar, y todas las referencias a la propiedad se cambian. Esto al menos no se puede hacer en TextMate, que utilizan muchos desarrolladores de Rails.

Por otro lado, la principal ventaja de Ruby on Rails es que es un lenguaje interpretado;) La naturaleza de Ruby, cómo puede modificar cualquier objeto en la memoria, o parchear un mono en una clase, puede conducir a algunas soluciones muy elegantes; mira el libro Eloquent Ruby para ver algunos ejemplos. Y gran parte del marco de Rails se basa en esta capacidad.

La capacidad de reemplazar cualquier método en cualquier objeto en cualquier momento también me ha ayudado mucho al escribir pruebas unitarias. En .NET, la inyección de dependencias y los contenedores IOC son prácticamente requisitos para crear código comprobable. Eso no es necesario en Ruby.

Editar:

Después de pensarlo, probablemente la característica principal de Rails es la migración de la base de datos. El marco ASP.NET MVC no proporciona en sí mismo ningún soporte de base de datos. El marco .NET tiene algunos componentes de acceso a datos / ORM, por ejemplo, Entity Framework y Linq to Sql. Pero no tiene ninguna herramienta para diseñar la estructura de la base de datos.

Si paga por una de las versiones más costosas de VS, puede obtener Data Dude , que le permite diseñar un esquema de base de datos y tener algunas herramientas para implementar el esquema en una base de datos. Pero por lo que puedo decir, el soporte para manejar las migraciones de versiones anteriores de la aplicación es muy limitado.

Algunos afirman que ASP.NET MVC no es realmente un marco MVC, simplemente un marco VC, debido a la falta de soporte para la migración de la base de datos.

Editar (nuevamente):

Los cambios en la cadena de herramientas / EF de Visual Studio han introducido migraciones basadas en código desde mi última edición. (pero también echa un vistazo a FluentMigrator si vas por ese camino)

Mi principal problema con MVC 3 de Microsoft y Entity Framework son sus principios de diseño asombrosamente malos.

Uno de los primeros problemas con los que me topé fue cuando utilicé otra clase como propiedad e intenté crear una lista desplegable para los posibles valores.

Para ilustrar mi punto, digamos que tiene dos clases de modelos como este:

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

Crear la propiedad Color sería suficiente para un ORM real pero no para EF. Debe agregar una ID redundante para la propiedad Color en la clase Thing de la siguiente manera:

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

Si no agrega el campo de ID redundante para una referencia de objeto extraño, no puede crear fácilmente listas desplegables con todas las opciones posibles de la clase vinculada.

Este es un diseño realmente terrible, ya que combina fuertemente el funcionamiento interno de una clase con otra. La cosa no debería saber nada sobre ColorID, la clase Color debería manejar sus propias verificaciones de igualdad sin exponer que incluso tiene una ID.

Estas son las mejores prácticas 101 cosas, pero aparentemente Microsoft desconoce por completo los principios básicos de la informática y la programación orientada a objetos. [/ Rant]