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

ASP.NET MVC e Rails hanno un'area d'uso simile, sono costruiti attorno alla stessa architettura, entrambi i framework sono relativamente nuovi e open source.

Quindi, come programmatore di Rails, vorrei sapere cosa possono fare ASP.NET MVC e Ruby on Rails, e viceversa?

Ho sviluppato applicazioni reali con Rails e ASP.NET MVC, ma questa risposta ha un avvertimento significativo: ho imparato e sviluppato con Rails pre-versione 2, quindi è del tutto possibile che io sia ampiamente obsoleto con il mio Conoscenza delle rotaie.

Detto questo, non penso che ci sia qualcosa che si possa fare con l'uno ma non con l'altro. Dato qualsiasi set 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 pulite 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, avrei un'azione che controlla se si tratta di un GET o 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, ma lo if request.post?schema è estremamente comune in Rails. Per casi non banali, il codice di azione può diventare grande e disordinato e, spesso, vorrei poterlo trasformare 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 riuscire a separare in modo chiaro la gestione delle richieste GET e POST sia pulito. Il tuo chilometraggio può variare.

L'altra cosa che ASP.NET MVC fa che è super cool (sempre secondo me) è anche legata alla gestione dei moduli POSTS. In Rails, devo interrogare l' paramshash per tutte le mie variabili di modulo. Diciamo che ho un modulo con i campi 'status', 'gonkulated', 'invert' e '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

Ma ASP.NET MVC mi consente ordinatamente di ottenere tutti i miei valori di modulo 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 adorato di ASP.NET MVC o Rails. Non sono sufficienti per uno sviluppatore sano o competente di 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 stimato su come dovrebbero essere strutturate le tabelle (la tabella deve avere una sola colonna intera come chiave primaria chiamata 'id', ecc.) Quindi se le tue tabelle esistenti non sono conformi alle preferenze di ActiveRecord, è difficile creare ActiveRecord opera. Ma sviluppare una nuova app con un nuovo db con ActiveRecord e Rails è veloce!

ASP.NET MVC non ha ORM predefinito. Puoi scegliere una strategia di accesso ai dati adatta alle tue esigenze. Alcuni ORM come Nhibernate possono supportare database legacy. Puoi avere la chiave primaria guid, ecc.

Esiste un'alternativa a Rails ActiveRecord chiamata DataMapper , ma non l'ho provato.

Avendo utilizzato sia, la risposta IMO è che ASP.NET MVC è più flessibile di Rails, se le vostre esigenze applicative a fare di più che semplicemente di lettura / scrittura da un database. Nella mia esperienza Rails si rompe rapidamente e pesantemente nel momento in cui introducete qualsiasi tipo di complessità o logica nell'applicazione oltre la logica CRUD molto banale. ASP.NET MVC non incontra questa limitazione poiché è più "aperto" su ciò che puoi fare.

A parità di altre condizioni in una tipica app CRUD "Web 2.0" non c'è nulla che si possa fare rispetto all'altra, ma per un'applicazione più complicata che necessita di un flusso di lavoro o di origini dati diverse o per interagire con un'altra applicazione o altro che non è un 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 dei tipi. Questo si presenta. Adam Crossland e rmac lo hanno toccato brevemente nei loro commenti, ma vorrei sottolineare che con un metodo controller come il seguente, ciascuno dei parametri sarà fortemente tipizzato. Ciò rende il codice all'interno del metodo Edit molto più pulito in quanto non devi preoccuparti di convertire le rappresentazioni di stringa in variabili digitate correttamente.

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

L'altro posto che mostra questo tipo di sicurezza è in Viste e Vista parziale in cui è possibile associare una vista di vista parziale con un oggetto C # vecchio normale, che servirà come modello di quella vista o vista parziale. Questo rende la vita molto più semplice, specialmente dove vuoi costruire una gerarchia di viste che contengono altre viste.

Se Infinity.ViewModels.Sitelo spazio dei nomi contiene una classe chiamata ContactViewModel, quindi per le viste 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>" %>

Associare l'istanza effettiva dell'oggetto modello alla vista nel metodo di azione Controller e quindi accedere all'istanza dell'oggetto modello nella vista dalla Modelproprietà della vista.

Questa tipicità, per me, è super cool. Il team che ha creato ASP.NET MVC ha dedicato molti sforzi per rendere fortemente tipizzate ciascuna delle 3 aree di Modello, Vista e Controller.

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

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

Ho usato ASP.NET MVC intorno alla versione originale ed era sicuramente un clone di Rails meno activerecord. Quindi, Rails ha quasi certamente un set di funzionalità molto più grande e un ecosistema plugin / gemma molto più grande.

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

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

D'altra parte, il vantaggio principale di Ruby on Rails è che è un linguaggio interpretato;) La natura di Ruby, come è possibile modificare qualsiasi oggetto in memoria o scimmiottare una classe in una classe, può portare ad alcune soluzioni molto eleganti; controlla il libro Rublo eloquente per alcuni esempi. E gran parte del framework Rails stesso si basa su questa capacità.

La possibilità di sostituire qualsiasi metodo in qualsiasi oggetto in qualsiasi momento mi ha anche aiutato molto nella scrittura di unit test. In .NET, i contenitori Iniezione delle dipendenze e IOC sono praticamente requisiti per la creazione di codice testabile. Questo non è necessario in Ruby.

Modificare:

Dopo averci pensato, 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 esempio 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 ti consente di progettare uno schema di database e avere alcuni strumenti per distribuire lo schema in un database. Ma per quanto ne so, il supporto per la gestione delle migrazioni da versioni precedenti dell'applicazione è molto limitato.

Alcuni sostengono che ASP.NET MVC non è in realtà 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 / EF di Visual Studio hanno introdotto migrazioni basate su codice dall'ultima modifica. (ma controlla anche FluentMigrator se stai seguendo quel percorso)

Il mio problema principale con l'MVC 3 di Microsoft e Entity Framework sono i loro principi di progettazione incredibilmente cattivi.

Uno dei primi problemi che ho riscontrato è stato quando ho usato un'altra classe come proprietà e ho cercato di creare un elenco a discesa per i possibili valori.

Per illustrare il mio punto, dire che si hanno 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; }
}

La creazione della proprietà Color sarebbe sufficiente per un ORM reale 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 accoppia fortemente i meccanismi interni di una classe all'altra. La cosa non dovrebbe sapere nulla su ColorID, la classe Color dovrebbe gestire i propri controlli di uguaglianza senza rivelare che ha anche un ID.

Questa è roba di best practice 101 ma apparentemente Microsoft non è del tutto consapevole dei principi di base dell'informatica e della programmazione orientata agli oggetti. [/ Rant]