Que peut faire ASP.NET MVC et que Ruby on Rails ne peut pas? [fermé]

ASP.NET MVC et Rails ont un domaine d'utilisation similaire, sont construits autour de la même architecture, les deux frameworks sont relativement nouveaux et open source.

En tant que programmeur Rails, j'aimerais savoir ce que ASP.NET MVC peut faire et que Ruby on Rails ne peut pas, et vice-versa?

J'ai développé de vraies applications avec Rails et ASP.NET MVC, mais cette réponse comporte une mise en garde importante: j'ai appris et développé avec la version 2 de Rails antérieure à la version 2, il est donc tout à fait possible que je sois totalement obsolète Rails connaissance.

Cela étant dit, je ne pense pas que l'on puisse faire quelque chose avec l'un mais pas avec l'autre. Si vous avez un ensemble d'exigences pour une application Web, vous devriez pouvoir créer cette application - probablement avec la même efficacité - avec Rails ou ASP.NET MVC.

À mon avis, il existe quelques fonctionnalités intéressantes disponibles dans ASP.NET MVC, principalement en raison de certains aspects de C # / .NET. Par exemple: quand j'ai une page contenant un formulaire soumis, j'aurais une action qui vérifie si elle traite d'un GET ou d'un POST pour décider quoi faire:

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

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

Ceci est un exemple trivial, mais le if request.post?motif est extrêmement répandu dans Rails. Pour les cas non triviaux, le code d'action peut devenir volumineux et compliqué, et souvent, je souhaiterais pouvoir le reformuler proprement dans des méthodes séparées. Dans ASP.NET MVC, je peux le faire:

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

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

Je pense que pouvoir séparer proprement le traitement des demandes GET et POST est très bien. Votre kilométrage peut varier.

L'autre chose que ASP.NET MVC fait qui est super cool (encore une fois à mon avis) est également liée à la gestion des formulaires POSTS. Dans Rails, je dois interroger le paramshachage pour toutes mes variables de formulaire. Disons que j'ai un formulaire avec les champs 'statut', 'gonkulated', 'invert' et '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

Mais ASP.NET MVC me permet parfaitement d’obtenir toutes mes valeurs de formulaire en tant que paramètres de ma méthode Action:

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

Ce sont les deux choses que j'ai vraiment aimé avec ASP.NET MVC ou Rails. Ils ne constituent pas une raison suffisante pour qu'un développeur sain d'esprit ou compétent puisse choisir un framework plutôt qu'un autre.

Un avantage d’ASP.NET MVC sur Rails réside dans le fait que vous devez créer une nouvelle application sur une base de données existante. Rails 'ActiveRecord est très déterminé sur la façon dont les tables doivent être structurées (la table doit avoir une et une seule colonne entière comme clé primaire appelée' id ', etc.) donc si vos tables existantes ne sont pas conformes aux préférences d'ActiveRecord, il est difficile de créer ActiveRecord. travail. Mais développer une nouvelle application avec une nouvelle base de données avec ActiveRecord et Rails est rapide!

ASP.NET MVC n'a pas d'ORM par défaut. Vous pouvez choisir une stratégie d'accès aux données qui répond à vos besoins. Certains ORM comme nhibernate peuvent prendre en charge des bases de données héritées. Vous pouvez avoir la clé primaire guid, etc.

Il existe une alternative à Rails ActiveRecord appelée DataMapper , mais je ne l'ai pas essayée.

Ayant utilisé à la fois, la réponse est que l' OMI ASP.NET MVC est plus flexible que Rails si vos besoins d'application de faire plus que juste lecture / écriture à partir d' une base de données. Selon mon expérience, Rails tombe en panne rapidement et lourdement dès que vous introduisez toute sorte de complexité ou de logique dans l'application, au-delà de la logique très triviale de CRUD. ASP.NET MVC ne rencontre pas cette restriction car il est plus "ouvert" sur ce que vous pouvez faire.

Toutes les autres fonctions étant identiques dans une application CRUD "Web 2.0" typique, vous ne pouvez rien faire d'autre qu'une tâche compliquée, mais pour une application plus complexe qui nécessite un flux de travail ou des sources de données disparates, ou pour interagir avec une autre application ou quoi que ce soit ce n'est pas typique de CRUD, ASP.NET peut faire beaucoup plus et ne pas être aussi restrictif que Rails.

Je n'ai jamais travaillé avec Ruby on Rails, je ne suis donc pas parfaitement qualifié pour répondre à cette question, mais une chose qui me plait le plus dans ASP.NET MVC est la sécurité de type. Cela vient de manière. Adam Crossland et rmac en ont brièvement parlé dans leurs commentaires, mais je voudrais souligner qu'avec une méthode de contrôleur comme celle-ci, chacun des paramètres sera fortement typé. Cela rend le code de la méthode Edit beaucoup plus propre car vous n'avez pas à vous soucier de la conversion des représentations de chaîne en variables correctement typées.

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

L'autre endroit où ce type de sécurité apparaît est dans Vues et Vue partielle, où l'on peut associer une vue de vue partielle à un objet Plain Old C #, qui servira de modèle pour cette vue ou cette vue partielle. Cela rend la vie beaucoup plus facile, en particulier lorsque vous souhaitez créer une hiérarchie de vues contenant d'autres vues.

Si Infinity.ViewModels.Siteest l'espace de noms contenant une classe appelée ContactViewModel, alors pour les vues Razor, vous le faites en plaçant une ligne comme celle-ci en haut de la vue:

@model Infinity.ViewModels.Site.ContactViewModel

et pour les vues ASPX, vous le faites en déclarant la vue de la façon suivante:

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

Vous associez l'instance réelle de l'objet de modèle à la vue dans la méthode d'action Controller, puis accédez à l'instance de l'objet de modèle dans la vue à l'aide de la Modelpropriété de la vue.

Cette force typée, pour moi, est super cool. L’équipe qui a créé ASP.NET MVC a déployé beaucoup d’efforts pour que chacune des trois zones Modèle, Vue et Contrôleur soit fortement typée.

Je ne sais pas si Ruby-on-Rails a cela, mais je l'espère bien.

Ils sont très similaires et peuvent tous «faire la même chose» la plupart du temps, mais certaines choses sont plus faciles chez l'un et plus difficiles que d'autres.

J'ai utilisé ASP.NET MVC autour de la version originale et c’était définitivement un clone de Rails moins activerecord. Donc, Rails a presque certainement un ensemble de fonctionnalités beaucoup plus grand et un écosystème de plugins / gemmes beaucoup plus grand.

Dans mon expérience limitée, le principal avantage de ASP.NET MVC est qu’il s’agit d’un langage compilé. Cela vous permet de détecter certains bogues de programmation déjà en cours de compilation, où Ruby doit s’appuyer sur cette détection lors des tests unitaires.

De plus, le fait qu’elle soit compilée permet d’avoir des outils de refactoring avancés, par exemple de changer le nom d’une propriété à un endroit donné, et toutes les références à la propriété sont modifiées. Cela au moins ne peut pas être fait dans TextMate, utilisé par de nombreux développeurs Rails.

D'autre part, l'avantage principal de Ruby on Rails est qu'il s'agit d'un langage interprété;) La nature de Ruby, la façon dont vous pouvez modifier n'importe quel objet en mémoire, ou assigner un singe à une classe, peut conduire à des solutions très élégantes; consultez le livre Eloquent Ruby pour quelques exemples. Et une grande partie du cadre Rails lui-même repose sur cette capacité.

La possibilité de remplacer n’importe quelle méthode à n’importe quel objet à tout moment m’a également beaucoup aidé à écrire des tests unitaires. Dans .NET, les conteneurs Dependency Injection et IOC sont pratiquement nécessaires à la création de code testable. Ce n'est pas nécessaire en Ruby.

Modifier:

Après réflexion, la fonctionnalité la plus meurtrière de Rails est probablement la migration de base de données. La structure ASP.NET MVC ne fournit en elle-même aucun support de base de données. Le framework .NET possède certains composants d'accès aux données / ORM, par exemple Entity Framework et Linq to Sql. Mais il ne dispose d'aucun outil pour concevoir la structure de la base de données.

Si vous payez pour l’une des versions les plus coûteuses de VS, vous pouvez obtenir le Data Dude , qui vous permet de concevoir un schéma de base de données et de disposer d’outils permettant de le déployer dans une base de données. Mais pour autant que je sache, la prise en charge de la gestion des migrations à partir de versions antérieures de l'application est très limitée.

Certains prétendent qu'ASP.NET MVC n'est pas vraiment une infrastructure MVC, mais simplement une infrastructure VC, en raison du manque de prise en charge de la migration de base de données.

Modifier (encore):

Les modifications apportées à la chaîne d'outils Visual Studio / EF ont introduit des migrations basées sur du code depuis ma dernière modification. (mais consultez également FluentMigrator si vous suivez cette voie)

Mon problème majeur avec MVC 3 et Entity Framework de Microsoft, ce sont leurs très mauvais principes de conception.

L'un des tout premiers problèmes que j'ai rencontrés a été l'utilisation d'une autre classe en tant que propriété et la création d'une liste déroulante pour les valeurs possibles.

Pour illustrer mon propos, disons que vous avez deux classes modèles comme celle-ci:

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 création de la propriété Color serait suffisante pour un ORM réel, mais pas pour EF. Vous devez ajouter un ID redondant pour la propriété Color dans la classe Thing, comme suit:

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 vous n'ajoutez pas le champ ID redondant pour une référence d'objet étranger, vous ne pourrez pas facilement créer de listes déroulantes avec toutes les options possibles de la classe liée.

C'est un design vraiment terrible car il couple fortement le fonctionnement interne d'une classe à une autre. Ce qui ne devrait rien savoir de ColorID, la classe Color devrait gérer ses propres contrôles d’égalité sans révéler qu’elle possède même un identifiant.

Il s’agit là de bonnes pratiques 101, mais apparemment, Microsoft n’est absolument pas au courant des principes de base de la science informatique et de la programmation orientée objet. [/ Rant]