it-swarm.it

Cosa può fare ASP.NET MVC e Ruby on Rails non può?

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 Rails vorrei sapere cosa può fare ASP.NET MVC e Ruby on Rails non è possibile e viceversa?

37
Nikita Barsukov

Ho sviluppato applicazioni reali con entrambi 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 sono enormemente obsoleto con la mia conoscenza Rails.

Detto questo, non penso che ci sia qualcosa che può essere fatto 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 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, ma il if request.post? pattern è 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 essere in grado di separare in modo chiaro la gestione di GET e POST è 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'hash params 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.

31
Adam Crossland

Un vantaggio di ASP.NET MVC rispetto a 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 e solo una colonna intera come chiave primaria chiamata 'id', ecc.) quindi se le tue tabelle esistenti non sono conformi alle preferenze di ActiveRecord, è difficile far funzionare ActiveRecord. 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.

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

6
Endy Tjahjono

Non ho mai lavorato con Ruby su 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. Adam Crossland e rmac lo hanno toccato brevemente nei loro commenti, ma vorrei sottolineare che con un metodo del controller come il seguente, ciascuno dei parametri sarà fortemente tipizzato. Questo rende il codice all'interno del metodo Edit molto più pulito in che 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.Site è lo spazio dei nomi che 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 mediante la proprietà Model della vista.

Questa tipicità, per me, è super cool. Il team che ha creato ASP.NET MVC ha speso molto sforzo 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.

2

Avendo usato entrambi, la risposta IMO è che ASP.NET MVC è più flessibile di Rails se l'applicazione deve fare più di solo leggi/scrivi 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 restrizione poiché è più "aperto" su cosa 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 è CRUD tipico, ASP.NET può fare molto di più e non essere così restrittivo come Rails.

2
Wayne Molina

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 Rails clone meno activerecord. Quindi, Rails ha quasi certamente un set di funzionalità molto più grande e un ecosistema plugin/gemma molto più grande.

1
scottschulthess

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 consente di disporre di strumenti avanzati di refactoring, ad es. cambia il nome di una proprietà in un unico posto e tutti i riferimenti alla proprietà vengono cambiati. Questo almeno non può essere fatto in TextMate, che molti usano Rails.

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 patch di scimmia una classe, può portare ad alcune soluzioni molto eleganti; dai un'occhiata al libro Eloquent Ruby per alcuni esempi. E gran parte del Rails il framework 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, Dependency Injection e IOC container sono praticamente requisiti per la creazione di codice testabile. Ciò 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, ma semplicemente un 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)

1
Pete