Was kann ASP.NET MVC und Ruby on Rails nicht? [geschlossen]

37

ASP.NET MVC und Rails haben einen ähnlichen Verwendungsbereich und basieren auf derselben Architektur. Beide Frameworks sind relativ neu und Open Source.

Als Rails-Programmierer würde ich gerne wissen, was ASP.NET MVC kann und was Ruby on Rails nicht und umgekehrt?

Nikita Barsukov
quelle
Gute Frage. Ich bin ein MVC-Entwickler und bin gespannt auf die Antwort darauf.
StuperUser
14
Diese Art von Fragen ist unbefristet und lässt sich besser über das Web IMHO beantworten. Was kann ein BMW 335, was eine Hyundai Sonata nicht kann? Sie haben beide 4 Versuche, ein Lenkrad und sind auf dem gleichen Verbrauchsgerüst aufgebaut; Treibstoff. Diese Fragen tauchen aufgrund mangelnder Forschung zum Verständnis der gegebenen Themen auf, was eine direktere Frage erleichtern kann .... Ich bin sicher, dass viele anderer Meinung sind, da dies Programmierer sind ...
Aaron McIver
1
@Aaron - Auch wenn ich mir die Mühe gemacht habe, eine Antwort auf diese Frage hinzuzufügen, stimme ich Ihnen im Prinzip zu und hoffe, dass ich klargestellt habe, dass wir ein Auto mit einem anderen vergleichen, um Ihr Analog zu leihen.
Adam Crossland
10
Ich persönlich hielt das für eine berechtigte Frage. Solche Fragen sollten nicht so schnell abgeschnitten werden, da viele von uns nur eine Seite der Geschichte kennen und es hilfreich ist, auch eine Vorstellung von der anderen Seite zu bekommen. Übrigens, eine Frage zu StackExchange zu stellen, qualifiziert sich als Recherche in meinem Buch.
Umar Farooq Khawaja
3
Ich stelle solche Fragen oft und lasse sie abschießen, deshalb möchte ich hier etwas Unterstützung für das OP zeigen. Bei der Codierung getroffene Entscheidungen sind fast immer subjektiv. Mein Recht könnte dein Unrecht sein, während beide funktionierende Lösungen von gleichem (subjektivem) Wert entwickeln könnten. In diesem Fall möchte das OP Stellungnahmen zu den relativen Vorzügen zweier sich gegenüberstehender Technologien einholen. Sie werden diese Informationen nirgendwo finden, außer in den Köpfen derjenigen, die den praktischen Prozess durchlaufen haben, eine über die andere zu wählen. Es ist daher eine berechtigte Frage.
Ian

Antworten:

31

Ich habe sowohl mit Rails als auch mit ASP.NET MVC echte Anwendungen entwickelt, aber diese Antwort bringt eine erhebliche Einschränkung mit sich: Ich habe mit Rails vor Version 2 gelernt und entwickelt Schienenwissen.

Abgesehen davon glaube ich nicht, dass es irgendetwas gibt , das mit dem einen gemacht werden kann, aber nicht mit dem anderen. Wenn Sie eine Reihe von Anforderungen für eine Webanwendung haben, sollten Sie in der Lage sein, diese App - wahrscheinlich ebenso effizient - mit Rails oder ASP.NET MVC zu erstellen.

Es gibt ein paar nette Dinge, die meines Wissens in ASP.NET MVC hauptsächlich aufgrund von Aspekten von C # /. NET verfügbar sind. Beispiel: Wenn ich eine Seite habe, die ein gesendetes Formular enthält, wird in einer Aktion geprüft, ob es sich um ein GET oder einen POST handelt, um zu entscheiden, was zu tun ist:

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

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

Dies ist ein triviales Beispiel dafür, aber das if request.post?Muster ist in Rails äußerst verbreitet. In nicht trivialen Fällen kann der Aktionscode groß und unübersichtlich werden, und häufig würde ich mir wünschen, dass ich ihn sauber in separate Methoden umgestalten könnte. In ASP.NET MVC kann ich das tun:

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

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

Ich denke, dass es in der Lage ist, die Behandlung von GET- und POST-Anfragen sauber zu trennen. Ihr Kilometerstand kann variieren.

Die andere Sache, die ASP.NET MVC macht, ist super cool (wieder meiner Meinung nach) und hat auch mit der Handhabung von Formular-POSTS zu tun. In Rails muss ich den paramsHash für alle meine Formularvariablen abfragen . Nehmen wir an, ich habe ein Formular mit den Feldern 'Status', 'Gonkuliert', 'Invertiert' und '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

Mit ASP.NET MVC kann ich jedoch alle meine Formularwerte als Parameter für meine Action-Methode abrufen:

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

Das sind die beiden Dinge, die ich an ASP.NET MVC oder Rails wirklich geliebt habe. Sie sind kein ausreichender Grund für einen vernünftigen oder kompetenten Entwickler, ein Framework vor dem anderen zu wählen.

Adam Crossland
quelle
6
Zu den Aktionsparametern: Das hätte ich mir gedacht public ActionResult Edit(Foothing foothing), dh die ModelBinder-Features waren noch ordentlicher.
rmac
10
Die Rails-Beispiele sind ziemlich veraltet. Sie funktionieren, aber es gibt bessere Möglichkeiten, dies zu tun.
Jason w
2
@Jason: Würdest du das gerne erweitern und vielleicht eine Zusammenfassung posten ?
Dan,
3
Ich bin damit einverstanden, dass die request.post? sieht für mich auch ungewöhnlich aus (vielleicht weil es in älteren Versionen verwendet wurde). Ich habe mit Rails 3 angefangen und die Editiermethode ist immer ein 'get'. Ich nehme an, Sie könnten es als Post konfigurieren, aber Rails verwendet ein RESTful-Muster, bei dem eine Aktualisierungsmethode verwendet wird, um Änderungen in einem Modell vorzunehmen. Wenn Sie das richtig gemacht haben, sollten Sie nicht einmal überprüfen müssen, ob es sich bei der Bearbeitungsmethode um einen Beitrag handelt.
PhillipKregg
3
Wählen Sie einfach, weil Sie ein vernünftiges Argument präsentieren. Ich bevorzuge Rails, aber es ist völlig subjektiv und Sie argumentieren Ihren Fall gut.
Steve Hill
6

Ein Vorteil von ASP.NET MVC gegenüber Rails besteht darin, dass Sie eine neue Anwendung über eine vorhandene Datenbank erstellen müssen. ActiveRecord von Rails ist sehr besorgt darüber, wie Tabellen strukturiert werden sollten (Tabelle muss eine und nur eine Ganzzahlspalte als Primärschlüssel mit der Bezeichnung 'id' usw. haben). Wenn Ihre vorhandenen Tabellen also nicht den ActiveRecord-Einstellungen entsprechen, ist es schwierig, ActiveRecord zu erstellen Arbeit. Aber die Entwicklung einer neuen App mit neuer Datenbank mit ActiveRecord und Rails geht schnell!

ASP.NET MVC verfügt nicht über Standard-ORM. Sie können eine Datenzugriffsstrategie auswählen, die Ihren Anforderungen entspricht. Einige ORMs wie nhibernate unterstützen ältere Datenbanken. Sie können guid Primärschlüssel usw. haben.

Es gibt eine Alternative zu Rails ActiveRecord namens DataMapper , die ich jedoch nicht ausprobiert habe.

Endy Tjahjono
quelle
9
Mit Rubys ActiveRecord können Sie eine Menge Code entfernen, wenn Sie bestimmte Konventionen einhalten, dies ist jedoch nicht erforderlich. Wenn die Konventionen nicht befolgt werden, müssen Sie expliziter sein.
Kevin Cline
1
ASP.NET MVC verfügt über das Entity Framework für ORM, das meiner Erfahrung nach bisher ziemlich beeindruckend war.
Cooper
Wenn Sie damit sagen, dass Sie schlecht generierte Abfragen 20-mal langsamer ausführen als richtig geschriebenes SQL, dann ja;) ... Dapper Contrib ist etwas, das ich großartig und schnell gefunden habe ...
niico
2

Nachdem Sie beide verwendet haben, lautet die Antwort IMO, dass ASP.NET MVC flexibler als Rails ist, wenn Ihre Anwendung mehr als nur Lesen / Schreiben aus einer Datenbank ausführen muss. Meiner Erfahrung nach geht Rails schnell und schwer kaputt, sobald Sie der Anwendung eine Komplexität oder Logik einführen, die über die sehr triviale CRUD-Logik hinausgeht. ASP.NET MVC ist von dieser Einschränkung nicht betroffen, da die Möglichkeiten "offener" sind.

Alles andere ist gleich in einer typischen "Web 2.0" CRUD App. Es gibt nichts, was man anders machen kann, aber für eine kompliziertere Anwendung, die einen Workflow oder unterschiedliche Datenquellen benötigt, oder um mit einer anderen Anwendung zu interagieren oder so das ist kein typisches CRUD, ASP.NET kann viel mehr und ist nicht so restriktiv wie Rails.

Wayne Molina
quelle
9
-1 Ich sehe keinen Grund, warum ASP.NET MVC als flexibler eingestuft werden könnte - wenn Sie sich die Hauptkomponenten, das Routing, die Controller und das Rendering ansehen, sind sie alle einfach verrückt und es fehlen auch viele Funktionen.
Scottschulthess
1
Wie ist asp.net mvc "offener"? Ich kann das ganze Gerüst-Gerüst-Ding überspringen und meine Modelle und Steuerungen von Grund auf neu erstellen und verschachtelte Assoziationen erstellen - eine zu viele, viele zu eine, viele zu viele - ohne dass es zu einem Zusammenbruch kommt. Und wenn ich mich für ein Javascript-schweres Frontend entscheide, kann ich alle meine Modelldaten genauso einfach in JSON (oder XML oder einem anderen Format) an den Client senden. Und wenn Sie sich eine Funktionalität vorstellen können, die Sie gerne implementieren würden, gibt es wahrscheinlich bereits ein Juwel dafür. Es ist nicht schwer, nicht-triviale Rails-Apps zu finden.
PhillipKregg
2
In der Lage zu sein, auf ein unformatiertes c # / .net-Framework herunterzufallen, könnte als flexibler angesehen werden?
Chris Barry
2
Sehr spät, aber was ich mit diesem Beitrag gemeint hatte, ist ASP.NET MVC, mit dem Sie zu C # /. NET wechseln und das gesamte Framework nutzen können. Die damaligen Rails (ich glaube, ich kann mich nicht erinnern, etwa 2,0) machten CRUD im Grunde genommen sehr einfach und alles andere schwierig. Das Projekt, an dem ich arbeitete, als ich dies schrieb, war in Rails ausgeführt (mein Fehler) und brach in der Minute zusammen, in der wir Logik jenseits von "Aus Datenbank lesen, auf Seite anzeigen" ausführten, wenn ich sie in C # / ASP.NET MVC ausgeführt hätte ( 1.0 zu diesem Zeitpunkt IIRC) Ich wäre nicht auf viele der Probleme gestoßen, die ich durch die Auswahl von Rails für die App hatte.
Wayne Molina
2

Ich habe noch nie mit Ruby on Rails gearbeitet, daher bin ich für die Beantwortung dieser Frage nicht besonders qualifiziert, aber eine Sache, die ich an ASP.NET MVC sehr mag, ist die Typensicherheit. Das kommt in die Quere. Adam Crossland und rmac haben es in ihren Kommentaren kurz angesprochen, aber ich möchte darauf hinweisen, dass bei einer Controller-Methode wie der folgenden jeder Parameter stark typisiert wird. Dadurch wird der Code in der Edit-Methode wesentlich übersichtlicher, da Sie sich nicht um die Konvertierung von Zeichenfolgendarstellungen in ordnungsgemäß typisierte Variablen kümmern müssen.

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

Die andere Stelle, an der diese Art der Sicherheit angezeigt wird, befindet sich in Ansichten und Teilansicht, wo eine Ansicht der Teilansicht einem einfachen alten C # -Objekt zugeordnet werden kann, das als Modell für diese Ansicht oder Teilansicht dient. Dies erleichtert das Leben erheblich, insbesondere wenn Sie eine Hierarchie von Ansichten erstellen möchten, die andere Ansichten enthalten.

Wenn Infinity.ViewModels.Siteder Namespace eine Klasse enthält, die aufgerufen wird ContactViewModel, platzieren Sie für Razor-Ansichten eine Zeile wie die folgende oben in der Ansicht:

@model Infinity.ViewModels.Site.ContactViewModel

Für ASPX-Ansichten deklarieren Sie die Ansicht folgendermaßen:

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

Sie verknüpfen die tatsächliche Instanz des Modellobjekts mit der Ansicht in der Controller-Aktionsmethode und greifen dann über die ModelEigenschaft der Ansicht auf die Instanz des Modellobjekts in der Ansicht zu.

Diese starke Typisierung ist für mich super cool. Das Team, das ASP.NET MVC erstellt hat, hat große Anstrengungen unternommen, um die drei Bereiche Modell, Ansicht und Controller stark zu typisieren.

Ich bin mir nicht sicher, ob Ruby-on-Rails dies hat, aber ich würde es hoffen.

Umar Farooq Khawaja
quelle
Die Ruby-Sprache ist ebenfalls stark typisiert (auch duck-typisiert). Rails verwendet Active Record, um seine Modelle automatisch mit seinen Ansichten zu verknüpfen. Sie müssten sie nicht im Controller deklarieren. Wenn Sie eine verschachtelte Hierarchie von Ansichten erstellen möchten, erstellen Sie im Controller eine Instanzvariable, die die Modelle darstellt, die Sie an die Ansicht übergeben möchten. Ja, sie können beide dasselbe tun.
PhillipKregg
1

Sie sind sich sehr ähnlich und sie können meistens alle "die gleichen Dinge tun", nur einige Dinge sind einfacher und schwieriger als andere.

Ich habe ASP.NET MVC für die ursprüngliche Version verwendet und es war definitiv ein Rails-Klon ohne Activerecord. Rails hat also mit ziemlicher Sicherheit ein viel größeres Feature-Set und ein viel größeres Plugin / Gem-Ökosystem.

scottschulthess
quelle
2
Stimmt - aber Rails gibt es auch schon seit ungefähr 8 Jahren, also hat es einen Vorsprung. Ich komme von Rails zu asp.net und MVC 3 ist eigentlich sehr nett. Das Entity Framework und der NuGet-Paketmanager waren für mich bisher sehr beeindruckend.
PhillipKregg
1

Nach meiner begrenzten Erfahrung besteht der Hauptvorteil von ASP.NET MVC darin, dass es sich um eine kompilierte Sprache handelt. Auf diese Weise können Sie einige Programmierfehler erkennen, die bereits beim Kompilieren aufgetreten sind. Ruby muss diese dann beim Testen von Einheiten erkennen.

Die Tatsache, dass es kompiliert wurde, ermöglicht erweiterte Refactoring-Tools, z. B. das Ändern des Namens einer Eigenschaft an einer Stelle, und alle Verweise auf die Eigenschaft werden geändert. Dies ist zumindest in TextMate, das viele Rails-Entwickler verwenden, nicht möglich.

Andererseits ist der Hauptvorteil von Ruby on Rails, dass es sich um eine interpretierte Sprache handelt. Die Art von Ruby, wie Sie ein beliebiges Objekt im Speicher ändern oder eine Klasse mit Affen patchen können, kann zu einigen sehr eleganten Lösungen führen. Schauen Sie sich das Buch Eloquent Ruby für einige Beispiele an. Ein großer Teil des Rails-Frameworks selbst basiert auf dieser Fähigkeit.

Die Möglichkeit, eine Methode jederzeit an einem beliebigen Objekt zu ersetzen, hat mir auch beim Schreiben von Komponententests sehr geholfen. In .NET sind Dependency Injection- und IOC-Container praktisch Voraussetzungen für die Erstellung von testbarem Code. Das ist in Ruby nicht nötig.

Bearbeiten:

Nachdem wir darüber nachgedacht haben, ist wahrscheinlich die Datenbankmigration das Killer-Feature von Rails. Das ASP.NET MVC-Framework bietet an sich keine Datenbankunterstützung. Das .NET Framework verfügt über einige Datenzugriffskomponenten / ORM, z. B. Entity Framework und Linq to SQL. Es stehen jedoch keine Tools zum Entwerfen der Datenbankstruktur zur Verfügung.

Wenn Sie für eine der teureren Versionen von VS bezahlen, können Sie den Data Dude erwerben , mit dem Sie ein Datenbankschema entwerfen können und über einige Tools zum Bereitstellen des Schemas in einer Datenbank verfügen. Soweit ich weiß, ist die Unterstützung für Migrationen aus früheren Versionen der Anwendung jedoch sehr begrenzt.

Einige behaupten, dass ASP.NET MVC nicht wirklich ein MVC-Framework, sondern lediglich ein VC-Framework ist, da die Datenbankmigration nicht unterstützt wird.

Bearbeiten (erneut):

Durch Änderungen an der Visual Studio-Toolchain / EF wurden seit meiner letzten Bearbeitung codebasierte Migrationen eingeführt. (Aber schauen Sie sich auch FluentMigrator an, wenn Sie diesen Weg gehen.)

Pete
quelle
2
Entity Framework 5.0 Code First unterstützt Migrationen
Hofnarwillie
Tatsächlich werden Code-First-Migrationen seit 4.1 unterstützt, das nicht allzu lange nach meiner Bearbeitung von AFAIK veröffentlicht wurde.
Pete
-1

Mein Hauptproblem mit MVC 3 und Entity Framework von Microsoft sind die verblüffend schlechten Designprinzipien.

Eines der allerersten Probleme, auf das ich gestoßen bin, war die Verwendung einer anderen Klasse als Eigenschaft und der Versuch, eine Dropdown-Liste für die möglichen Werte zu erstellen.

Um meinen Standpunkt zu veranschaulichen, sagen Sie, Sie haben zwei Modellklassen wie diese:

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

Das Erstellen der Color-Eigenschaft würde für ein echtes ORM ausreichen, jedoch nicht für EF. Sie müssen eine redundante ID für die Color-Eigenschaft in der Thing-Klasse wie folgt hinzufügen:

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

Wenn Sie das redundante ID-Feld für eine Fremdobjektreferenz nicht hinzufügen, können Sie nicht einfach Dropdown-Listen mit allen möglichen Optionen der verknüpften Klasse erstellen.

Dies ist ein wirklich schreckliches Design, da es die internen Abläufe einer Klasse stark mit denen einer anderen koppelt. Wenn eine Sache nichts über ColorID wissen soll, sollte die Color-Klasse ihre eigenen Gleichheitsprüfungen durchführen, ohne auch nur eine ID preiszugeben.

Das sind Best Practices 101, aber anscheinend kennt Microsoft die Grundprinzipien der Informatik und der objektorientierten Programmierung überhaupt nicht. [/ Rant]

Mike Bethany
quelle
8
Sie benötigen keine Fremdschlüsseleigenschaft für Ihre Entity-Framework-Objekte. Außerdem ist EF ein vollständig separates Produkt und in keiner Weise in ASP.NET MVC integriert. Sie sollten Ansichtsmodelle verwenden, um Ihre Benutzeroberfläche zu erstellen und Dropdown-Listen oder andere Steuerelemente zu erstellen.
Lucifer Sam
Genau. Sie sollten überhaupt keine ID-Schlüssel in Ihren Entitäts-Frameworks haben. Ein ORM sollte die Objektidentität behandeln. Aber Punkt genommen; Ich beschwere mich wirklich mehr über das schreckliche EF ORM. Das Beispiel ist eine vereinfachte Version, die übrigens direkt von Microsoft stammt. Genau so machen sie es in ihrem ContosoUniversity-Beispiel. Das spricht für mich. Microsoft weiß nicht, wie man MVC oder ORM ausführt, und ihre Beispiele zeigen es.
Mike Bethany
1
Durch Hinzufügen der ColorID-Eigenschaft können Sie verzögerte Lademuster implementieren, was manchmal sehr nützlich ist. Wenn zum Beispiel das referenzierte Objekt sehr groß ist und Sie nicht wirklich alle Eigenschaftswerte des Objekts benötigen, wäre es eine Verschwendung von Verarbeitungszeit, alles nur abzurufen, um den zugehörigen ID-Teil davon zu finden (ColorID). . Außerdem können Sie nullbare / nicht nullbare Fremdschlüssel implementieren, dh was ist, wenn Farbe nicht immer benötigt wird? Ändern Sie die ColorID in eine Nullable Integerint?
Hofnarwillie