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

37

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?

Nikita Barsukov
la source
Excellente question. Je suis un développeur MVC et j'ai hâte de connaître la réponse à cette question.
StuperUser le
14
Ces types de questions sont ouvertes et il vaut mieux y répondre en surveillant le Web à mon humble avis. Que peut faire une BMW 335 à la Hyundai Sonata? Ils ont tous deux 4 essais, un volant et sont construits sur le même cadre de consommation; carburant. Ces questions surgissent en raison d'un manque de recherche sur la compréhension des sujets donnés, ce qui peut faciliter une question plus directe ... Je suis sûr que beaucoup ne seront pas d'accord, car il s'agit de programmeurs ...
Aaron McIver,
1
@Aaron - Même si j'ai eu la peine d'ajouter une réponse à cette question, je suis d'accord avec vous en principe et j'espère avoir bien précisé que pour emprunter votre analogue, nous comparons une voiture à une autre.
Adam Crossland le
10
J'ai personnellement pensé que c'était une question valide. De telles questions ne devraient pas être éliminées aussi facilement, car bon nombre d’entre nous ne connaissons qu’un côté de l’histoire et il est également utile de se faire une idée de l’autre. BTW, poser une question sur StackExchange est considéré comme une recherche dans mon livre.
Umar Farooq Khawaja
3
Je pose souvent des questions comme celle-ci et je les fais abattre, alors j'aimerais montrer ici un peu de soutien pour le PO. Les décisions prises lors du codage sont presque toujours subjectives. Mon droit pourrait être votre tort alors que les deux pourraient développer des solutions de travail de mérite égal (subjectif). Dans ce cas, le PO veut des opinions sur les mérites relatifs de deux technologies opposées. Vous ne trouverez cette information nulle part ailleurs que dans la tête de ceux qui ont suivi le processus pratique consistant à choisir l’une sur l’autre. C'est donc une question légitime.
Ian

Réponses:

31

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.

Adam Crossland
la source
6
En ce qui concerne les paramètres d'action: j'aurais pensé que public ActionResult Edit(Foothing foothing)les fonctionnalités de ModelBinder étaient encore meilleures.
Rmac
10
Les exemples de rails sont assez démodés. Ils fonctionnent, mais il existe de meilleures façons de le faire.
Jason
2
@ Jason: voudriez-vous développer et peut-être poster un résumé ?
Dan
3
Je suis d'accord que le request.post? me semble également inhabituel (peut-être parce qu’il a été utilisé dans des versions plus anciennes). J'ai commencé avec Rails 3 et la méthode d'édition est toujours un "get". Je suppose que vous pouvez le configurer pour qu'il s'agisse d'une publication, mais Rails utilise un modèle RESTful qui utilise une méthode de «mise à jour» pour effectuer la publication de toutes les modifications susceptibles de se produire dans un modèle. Donc, si cela est fait correctement, vous ne devriez même pas avoir à vérifier si la méthode 'edit' était une publication.
PhillipKregg
3
Vous voter simplement parce que vous présentez un argument sensé. Je préfère Rails, mais c'est entièrement subjectif et vous défendez bien votre cause.
Steve Hill
6

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.

Endy Tjahjono
la source
9
Ruby ActiveRecord vous permet d'éliminer beaucoup de code si vous suivez certaines conventions, mais ce n'est pas obligatoire. Si les conventions ne sont pas suivies, vous devez être plus explicite.
Kevin Cline
1
ASP.NET MVC possède Entity Framework for ORM, ce qui est pour moi une expérience formidable jusqu’à présent.
Cooper
Si, par génial, vous voulez dire que l'exécution de requêtes mal générées est 20 fois plus lente que le SQL correctement écrit, alors oui;) ... Dapper Contrib est quelque chose que j'ai trouvé génial et rapide ...
niico
2

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.

Wayne Molina
la source
9
-1 Je ne vois aucune raison pour qu'ASP.NET MVC soit considéré comme plus flexible - si vous examinez les principaux composants, le routage, les contrôleurs, le rendu, ils ne font que déchirer les rails et manquent également de nombreuses fonctionnalités.
scottschulthess
1
Comment asp.net mvc est-il «plus ouvert»? Je peux ignorer tout ce qui concerne l'échafaudage brut et créer mes modèles et contrôleurs à partir de zéro, en plus de créer des associations imbriquées - une à plusieurs, plusieurs à une, plusieurs à plusieurs - sans aucune "panne". Et, si je décide d'utiliser un front-end lourd javascript, je peux tout aussi facilement envoyer toutes les données de mon modèle au client au format JSON (ou XML, ou tout autre format). De plus, si vous pouvez penser à une fonctionnalité que vous souhaitez implémenter, il existe probablement déjà un bijou pour cela. Il n'est pas difficile de trouver des applications Rails non-triviales.
PhillipKregg
2
Etre capable de descendre au framework brut c # / .net pourrait être considéré comme plus flexible?
Chris Barry
2
Très tard sur ce sujet, mais ce que je voulais dire par ce billet est ASP.NET MVC vous permet de passer en C # / .NET et de tirer parti de toute la structure. Les rails à l'époque (autour de 2,0 je pense? Je ne me souviens plus) ont rendu CRUD très facile et tout le reste difficile; le projet sur lequel je travaillais quand j'ai écrit cela a été fait dans Rails (mon erreur) et a éclaté dès que nous avons fait la logique au-delà de "lire dans la base de données, afficher dans la page", si je l'avais fait en C # / ASP.NET MVC ( 1.0 à ce stade IIRC) Je n'aurais pas rencontré beaucoup des problèmes que j'avais rencontrés en choisissant Rails pour l'application à la place.
Wayne Molina
2

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.

Umar Farooq Khawaja
la source
Le langage Ruby est également très typé (également typé canard). Et Rails utilise l'enregistrement actif pour associer automatiquement ses modèles à ses vues. Vous n'avez pas besoin de les déclarer dans le contrôleur. Si vous souhaitez créer une hiérarchie de vues imbriquée, vous devez créer une variable d'instance dans le contrôleur représentant les modèles à transférer à la vue. Alors oui, ils peuvent tous les deux faire la même chose.
PhillipKregg
1

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.

scottschulthess
la source
2
C'est vrai - mais Rails existe également depuis environ 8 ans et a donc une longueur d'avance. Je viens de Rails pour asp.net et MVC 3 est en fait très agréable. Entity Framework et le gestionnaire de paquets NuGet ont été très impressionnants pour moi jusqu'à présent.
PhillipKregg
1

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)

Pete
la source
2
Entity Framework 5.0 Code First prend en charge les migrations
hofnarwillie
En fait, les premières migrations de code ont été prises en charge depuis la version 4.1, qui a été publiée par AFAIK peu de temps après ma modification.
Pete
-1

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]

Mike Bethany
la source
8
Vous n'avez pas besoin d'une propriété de clé étrangère sur vos objets de structure d'entité. En outre, EF est un produit complètement séparé et n’est en aucun cas intégré à ASP.NET MVC. Vous devriez utiliser des modèles de vue pour construire votre interface utilisateur et pour construire des listes déroulantes ou d’autres contrôles.
Lucifer Sam
Je suis d'accord. Vous ne devriez pas avoir de clés d'identification du tout dans vos frameworks d'entités. Un ORM doit gérer l'identité de l'objet. Mais point pris; Je me plains beaucoup plus du terrible ORM EF. Cet exemple est une version simplifiée venant directement de Microsoft, soit dit en passant. C'est exactement ce qu'ils font dans leur exemple ContosoUniversity. Cela parle à mon point. Microsoft ne sait pas faire MVC ou ORM et leurs exemples le montrent.
Mike Bethany
1
L'ajout de la propriété ColorID vous permet d'implémenter des modèles de chargement paresseux, ce qui est parfois très utile. Par exemple, si l'objet référencé est très volumineux et que vous n'avez pas vraiment besoin de toutes les valeurs de propriété de l'objet, il serait alors une perte de temps de traitement de le récupérer uniquement pour en trouver l'ID partie associée (ColorID). . Cela vous permet également d'implémenter des clés étrangères Nullable / Non Nullable, c'est-à-dire si la couleur n'est pas toujours nécessaire? Changez le ColorID en un entier int?
nul