Cosa può fare ASP.NET MVC e Ruby on Rails no? [chiuso]

Ho sviluppato applicazioni reali con Rails e ASP.NET MVC, ma questa risposta viene fornita con un avvertimento significativo: ho imparato e sviluppato con la versione precedente 2 Rails, quindi è del tutto possibile che io sia ampiamente fuori data con la mia conoscenza di Rails.

Detto questo, non penso che ci sia qualcosa che può essere fatto con uno, ma non con l'altro. Dato qualsiasi insieme di requisiti per un'applicazione web, dovresti essere in grado di creare quell'app - probabilmente in modo altrettanto efficiente - con Rails o ASP.NET MVC.

Ci sono un paio di cose belle che, per quanto ne so, sono disponibili in ASP.NET MVC principalmente a causa di aspetti di C # /. NET. Ad esempio: quando ho una pagina che contiene un modulo che viene inviato, vorrei avere un'azione che controlli per vedere se si tratta di un GET o di un POST per decidere cosa fare:

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

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

Questo è un esempio banale di esso, ma il pattern if request.post? è estremamente comune in Rails. Per i casi non banali, il codice di azione può diventare ingombrante e spesso, mi piacerebbe che potessi rifattenerlo in metodi separati in modo pulito. In ASP.NET MVC posso farlo:

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

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

Penso che essere in grado di separare nettamente la gestione delle richieste GET e POST sia accurato. Il tuo chilometraggio può variare.

L'altra cosa che ASP.NET MVC fa è super cool (sempre secondo me) è anche legata alla gestione dei POS POSTI. In Rails, devo interrogare l'hash params per tutte le variabili del mio modulo. Diciamo che ho un modulo con i campi 'status', 'gonkulated', 'invert' e 'disposizione':

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

Ma ASP.NET MVC mi consente di ottenere tutti i miei valori di form come parametri per il mio metodo Action:

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

Queste sono le due cose che ho veramente amato di ASP.NET MVC o Rails. Non sono una ragione sufficiente per uno sviluppatore sano o competente per scegliere un framework rispetto all'altro.

Un vantaggio di ASP.NET MVC su Rails è se è necessario creare una nuova applicazione su un database esistente. ActiveRecord di Rails è molto motivato su come le tabelle dovrebbero essere strutturate (la tabella deve avere una sola colonna di interi come chiave primaria chiamata 'id', ecc.) Quindi se le tue tabelle esistenti non sono conformi alle preferenze di ActiveRecord, è difficile rendere ActiveRecord lavoro. Ma lo sviluppo di nuove app con nuovi db con ActiveRecord e Rails è veloce!

ASP.NET MVC non ha l'ORM predefinito. È possibile scegliere una strategia di accesso ai dati adatta alle proprie esigenze. Alcuni ORM come il Nibernato possono supportare database legacy. Puoi avere la chiave primaria di guida, ecc.

C'è un alternativa a Rails ActiveRecord chiamato DataMapper , ma non l'ho provato.

Avendo usato entrambi, la risposta IMO è che ASP.NET MVC è più flessibile di Rails se l'applicazione deve fare più di solo in lettura / scrittura da un database. Nella mia esperienza, Rails si rompe rapidamente e pesantemente nel momento in cui si introduce qualsiasi tipo di complessità o logica per l'applicazione oltre la logica CRUD molto banale. ASP.NET MVC non incontra questa restrizione poiché è più "aperto" su ciò che puoi fare.

A parità di tutte le altre in una tipica app CRUD Web 2.0 non c'è nulla che si possa fare sull'altra, ma per un'applicazione più complicata che ha bisogno di un flusso di lavoro, di fonti di dati eterogenee o di interagire con un'altra applicazione , o qualsiasi cosa che non sia tipico CRUD, ASP.NET può fare molto di più e non essere così restrittivo come Rails.

Non ho mai lavorato con Ruby on Rails, quindi non sono esattamente qualificato per rispondere a questa domanda, ma una cosa che mi piace di ASP.NET MVC è immensamente la sicurezza del tipo. Questo arriva in modo Adam Crossland e rmac l'hanno accennato brevemente nei loro commenti, ma vorrei sottolineare che con un metodo di controllo come il seguente, ognuno dei parametri sarà strongmente digitato. Questo rende il codice all'interno del metodo Edit molto più pulito in quanto non ti devi preoccupare di convertire le rappresentazioni di stringa in variabili tipizzate correttamente.

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

L'altro posto in cui appare questo tipo di sicurezza è in Viste e Vista parziale dove è possibile associare una vista di vista parziale con un oggetto Plain Old C #, che servirà come modello di quella vista o vista parziale. Ciò rende la vita molto più semplice, soprattutto dove vuoi costruire una gerarchia di viste che contenga altre viste.

Se Infinity.ViewModels.Site è lo spazio dei nomi contenente una classe chiamata ContactViewModel , quindi per le visualizzazioni Razor, lo fai posizionando una linea come questa nella parte superiore della vista:

@model Infinity.ViewModels.Site.ContactViewModel

e per le viste ASPX, lo fai dichiarando la vista in questo modo:

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

Si associa l'istanza effettiva dell'oggetto modello con la vista nel metodo di azione Controller e quindi si accede all'istanza dell'oggetto modello nella vista dalla proprietà Model della vista.

Questa strong dattilografia, per me, è super cool. Il team che ha creato ASP.NET MVC ha dedicato molto impegno a rendere strongmente digitato ciascuna delle 3 aree del modello, della vista e del controller.

Non sono sicuro che Ruby-on-Rails abbia questo, ma lo spero.

Sono molto simili e possono tutti "fare le stesse cose" per lo più, solo alcune cose sono più facili in una e più difficili delle altre.

Ho usato ASP.NET MVC attorno alla versione originale ed è stato sicuramente un clone di Rails meno activerecord. Quindi, Rails ha quasi sicuramente un set di funzionalità molto più grande e un ecosistema plug-in / gem molto più grande.

Nella mia esperienza limitata, il vantaggio principale di ASP.NET MVC è che si tratta di un linguaggio compilato. Ciò consente di rilevare alcuni bug di programmazione già in fase di compilazione, in cui Ruby deve fare affidamento sulla rilevazione durante i test dell'unità.

Inoltre il fatto che sia compilato rende possibile avere strumenti di refactoring avanzati, ad es. cambia il nome di una proprietà in un posto e tutti i riferimenti alla proprietà sono cambiati. Questo almeno non può essere fatto in TextMate, che usano molti sviluppatori Rails.

D'altra parte, il vantaggio principale di Ruby on Rails è che è un linguaggio interpretato;) La natura di Ruby, come puoi modificare qualsiasi oggetto in memoria o patch di scimmia di classe, può portare ad alcuni molto eleganti soluzioni; consulta il libro Eloquent Ruby per alcuni esempi. E gran parte dello stesso framework Rails si basa su questa capacità.

Anche la possibilità di sostituire qualsiasi metodo con qualsiasi oggetto in qualsiasi momento mi ha aiutato molto nello scrivere i test unitari. In .NET, Dependency Injection e contenitori IOC sono praticamente requisiti per la creazione di codice verificabile. Non è necessario in Ruby.

Modifica:

Dopo aver riflettuto su questo, probabilmente la caratteristica killer di Rails è la migrazione del database. Il framework ASP.NET MVC non fornisce di per sé alcun supporto per il database. Il framework .NET ha alcuni componenti di accesso ai dati / ORM, ad es. Entity Framework e Linq to Sql. Ma non ha strumenti per progettare la struttura del database.

Se paghi per una delle versioni più costose di VS, puoi ottenere Data Dude , che consente di progettare uno schema di database e di disporre di alcuni strumenti per la distribuzione dello schema in un database. Ma per quanto posso dire, il supporto per la gestione delle migrazioni da versioni precedenti dell'applicazione è molto limitato.

Alcuni sostengono che ASP.NET MVC non sia realmente un framework MVC, semplicemente un framework VC, a causa della mancanza di supporto per la migrazione del database.

Modifica (di nuovo):

Le modifiche alla toolchain di Visual Studio / EF hanno introdotto migrazioni basate su codice dalla mia ultima modifica. (ma controlla anche FluentMigrator se stai seguendo questo percorso)

Il mio problema principale con Microsoft MVC 3 e Entity Framework sono i loro sconcertanti principi di progettazione.

Uno dei primi problemi che ho incontrato è stato quando si utilizzava un'altra classe come proprietà e si cercava di creare un elenco a discesa per i valori possibili.

Per illustrare il mio punto di vista, hai due classi modello come questa:

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

Creare la proprietà Color sarebbe sufficiente per un vero ORM ma non per EF. Devi aggiungere un ID ridondante per la proprietà Color nella classe Thing in questo modo:

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 non si aggiunge il campo ID ridondante per un riferimento a un oggetto estraneo non è possibile creare facilmente elenchi a discesa con tutte le opzioni possibili dalla classe collegata.

Questo è un design davvero terribile in quanto unisce strongmente i meccanismi interni di una classe all'altra. La cosa non dovrebbe sapere nulla di ColorID, la classe Color dovrebbe gestire i propri controlli di uguaglianza senza esporre che ha persino un ID.

Questa è una best practice 101 ma apparentemente Microsoft è totalmente inconsapevole dei principi di base dell'informatica e della programmazione orientata agli oggetti. [/ rant]