Aspnetcore: MVC est trop complexe pour être utilisable ?

Créé le 26 janv. 2019  ·  26Commentaires  ·  Source: dotnet/aspnetcore

Votre demande de fonctionnalité est-elle liée à un problème ? Décrivez s'il vous plait.

J'évalue MVC. Le problème semble être que MVC est une science de fusée alambiquée, mais je dois manquer quelque chose. Veuillez expliquer pourquoi quelqu'un utiliserait MVC sur les formulaires Web ASP.NET et la classe SqlCommand d'Entity FrameWork.

Décrivez la solution que vous souhaitez

Je veux joindre facilement plusieurs tables et pouvoir déboguer le résultat. Mais même une simple jointure est incroyablement complexe.

Décrivez les alternatives que vous avez envisagées

Perdez la science de fusée ou suggérez des procédures alternatives que l'on peut comprendre sans exiger des années d'étude. Ou veuillez me confirmer que l'utilisation de formulaires Web ASP.NET avec la classe SqlCommand d'Entity FrameWork est en effet une approche plus simple.

J'ai joint deux captures d'écran de l'exemple MVC de Contoso University. Veuillez expliquer comment quelqu'un est censé comprendre ce qui se passe ? Je ne peux même pas voir le jeu de résultats dans la fenêtre Watch. Et la requête qui est générée - qui est également jointe - ... bon dieu, tu te moques de moi ? Pour quoi devrait être une simple jointure ? Et si je dois déboguer ça ?

Qu'est-ce qui me manque dans cette évaluation autre qu'une année de vie monastique devant Visual Studio pour découvrir cette approche de conception déclarative pour créer un site Web ?

Une réponse claire et concise est grandement appréciée.

Merci.

screen shot 2019-01-26 at 1 24 01 pm
screen shot 2019-01-26 at 1 24 45 pm

Contexte supplémentaire

Ajoutez ici tout autre contexte ou capture d'écran concernant la demande de fonctionnalité.

area-mvc

Commentaire le plus utile

Si vous n'êtes pas fan des ORM (Object Relation Mappers) comme EntityFramework, vous pouvez écrire le SQL à la main en utilisant ADO.NET. Vous pouvez également utiliser un ORM léger comme Dapper qui ne génère pas de requêtes (vous pouvez les écrire à la main). EntityFramework dispose également d'une méthode ExecuteSQL pour vous donner plus de contrôle si nécessaire (https://docs.microsoft.com/en-us/ef/core/querying/raw-sql).

Tous les 26 commentaires

Si vous n'êtes pas fan des ORM (Object Relation Mappers) comme EntityFramework, vous pouvez écrire le SQL à la main en utilisant ADO.NET. Vous pouvez également utiliser un ORM léger comme Dapper qui ne génère pas de requêtes (vous pouvez les écrire à la main). EntityFramework dispose également d'une méthode ExecuteSQL pour vous donner plus de contrôle si nécessaire (https://docs.microsoft.com/en-us/ef/core/querying/raw-sql).

De plus, si MVC semble trop complexe pour des pages simples, essayez Razor Pages

Je vous suggère fortement de suivre l'un des nombreux tutoriels MVC ; on ne peut pas s'attendre à comprendre quelque chose comme par magie en seulement 5 minutes en regardant le nouveau modèle de projet.

En ce qui concerne la simplicité relative aux formulaires Web, puis-je vous rappeler le malheur de viewstate, runat=server et god save us all from the page lifecycle.
Sincères amitiés

C'est drôle.

Cela me semble assez simple.

De plus, si MVC semble trop complexe pour des pages simples, essayez Razor Pages

Je viens de terminer un projet de migration WebForms -> RazorPages - Pour être honnête, cela aurait pu être simplement MVC, mais certainement une bonne option pour les petits sites Web « centrés sur la page ». Dans les projets MVC, je trouve que je "chasse" trop de code, c'est-à-dire. sauter constamment de la vue au contrôleur, faire défiler des tonnes d'actions alors que dans RazorPages, je vais directement aux PageModels.

Je déteste EF gonflé - Dapper est tellement plus simple, surtout s'il est utilisé avec quelque chose comme Dapper.FastCRUD

Ce n'est pas seulement vous @LJ9999 , MVC et tout framework n'ont pas toutes les réponses. Ce n'est peut-être pas la meilleure structure adaptée à votre projet, et cela peut ne pas correspondre à votre façon de penser. Pas besoin d'essayer d'insérer des chevilles carrées dans des trous ronds, sauf si vous aimez l'auto-punition.

MVC est l'une de vos options. Évaluez quelques approches différentes et choisissez celle qui vous convient le mieux. Trouvez quelque chose qui a du sens pour vous. Trouvez (ou faites) quelque chose dans lequel vous êtes le plus productif. Ne vous laissez pas influencer par ce qui est populaire. La popularité n'est pas toujours une question de mérite, et même ce qui est un mérite pour un cas ne fonctionne pas ailleurs.

Alors permettez-moi de me joindre à vous pour être sceptique quant à la manière la plus courante de faire les choses. Être sceptique quant à l'approche que chacun adopte et penser de manière critique et pour vous-même est un bon point de départ. Si vous pensez que vous pouvez faire mieux, vous le pouvez probablement. Fonce!

Pour tous ceux qui lisent et ressentent cela comme une attaque contre eux et contre la manière populaire qu'ils ont choisie, ce n'est vraiment pas une attaque contre vous. Il dit trouver ce qui fonctionne pour vous. Et donc c'est juste une déclaration sur le fait que, alors que les ordinateurs peuvent tous fonctionner sur le même langage, l'esprit des gens ne le fait pas. Tout le monde est différent et c'est très bien.

+1 à pimpant, utilisez-le.

Quant à la raison pour laquelle vous utilisez le framework d'entité, c'est un moyen rapide et facile d'exprimer votre comportement souhaité dans le même langage que celui dans lequel vous définissez votre code, avec le support de génération de code (lire : temps de mise sur le marché réduit). Je ne l'utilise généralement pas, et vous n'êtes pas obligé non plus.

Il semble que vous soyez peut-être plus en désaccord avec son utilisation dans un exemple. La réponse à cela est le public cible : plus de personnes connaissent les paradigmes ORM en 2019 que de personnes réellement compétentes en SQL. SQL n'est pas mort, il a juste beaucoup de concurrence forte avec une forte pénétration dans le contingent de développeurs plus jeunes.

En tant que personne qui a parcouru toutes les itérations d'Asp.Net et de MVC jusqu'à ce que nous avons maintenant avec Asp.Net Core, je peux vous dire que le débogage des bogues du cycle de vie des pages et essayer de créer quoi que ce soit d'une complexité relative avec les formulaires Web était un cauchemar comparé à MVC. Les formulaires Web cachent une grande partie du travail réel derrière ce qui semble être des événements magiques. Il résume tout le fonctionnement des requêtes Web en essayant de vous tenir la main et de prétendre que le Web n'est pas sans état. Il vous ment et vous dit que vous êtes jolie et que vos fesses vont bien dans ce jean. Cela renforce faussement votre confiance et rend les technologies Web floues. Et vous continuez joyeusement votre journée en pensant que si vous pouvez créer une page Web avec un formulaire et l'enregistrer dans une table, vous pouvez tout faire. Jusqu'à ce que vous obteniez cette nouvelle exigence pour créer un formulaire dynamique personnalisé. Ou faire fonctionner quelque chose avec ce framework côté client particulier, parce que le client pense que c'est joli. Vous réalisez que vous travaillez maintenant à contre-courant et vous vous demandez comment tout le monde le fait.
MVC n'est pas sorcier, c'est un modèle éprouvé qui a évolué dans la communauté du développement après avoir réalisé "qu'il doit y avoir un meilleur moyen" et des années à coller des chevilles rondes dans des trous carrés. Si vous pensez que c'est compliqué, c'est probablement parce que vous n'avez rencontré aucun des problèmes qu'il est censé résoudre et que vous n'avez pas passé assez de temps à résoudre des problèmes complexes. Commencez par des tutoriels plus simples si celui-ci est écrasant.
Si vous décidez que ce n'est pas pour vous, il y a toujours PHP ou NodeJs.

Pour quelque chose qui est plus qu'une simple jointure, j'utiliserais simplement ExecuteSQL d'EF. Je pense que vous pourriez sous-estimer la complexité qu'il pourrait essayer de représenter car il n'a pas de moyen de nommer logiquement les tables de jointure et il pourrait être nécessaire d'être flexible avec l'affectation du bureau. Si vous n'aimez pas EF, vous n'êtes pas seul. La plupart des gens qui utilisent MVC n'utilisent probablement pas EF. L'un n'exige pas l'autre.

Personnellement, je trouve que les formulaires Web sont beaucoup plus compliqués que MVC car ils ont tellement de logique d'événement complexe obscurcissant ce qui est en fait un cycle de réponse à la demande. MVC pour quelqu'un qui n'y a jamais pensé est difficile au début car il s'agit d'un modèle d'organisation différent, mais après des années d'utilisation, l'industrie semble avoir décidé que MVC est en fait plus simple à long terme. C'est juste une question de préférence, mais ouvrir un ticket comme celui-ci sur une technologie qui est courante depuis des années n'est qu'une décharge.

Je recommande d'apprendre MVC avec des exemples qui n'utilisent pas le framework d'entité afin que vous appreniez un seul concept à la fois. Cependant, ce n'est pas vraiment le bon endroit pour en parler.

OMG je ris tellement fort en ce moment.

Regardez mon pote, si cela semble trop difficile ou complexe, éloignez-vous-en et utilisez autre chose. Personne ne vous pointe une arme sur la tempe, n'est-ce pas ?

Certains d'entre nous ont fait le tour du bloc à quelques reprises et préfèrent la simplicité d'asp mvc aux formulaires Web, car nous avons dû faire face à l'horrible pile de code spaghetti intestable qui provient des monstruosités des formulaires Web monolithiques.

Mais sérieusement, si vous aimez les formulaires Web et que quelqu'un est prêt à vous payer pour coder des formulaires Web, alors faites-le ! Et arrêtez de vous plaindre de choses que vous ne comprenez pas.

Est-ce un article satirique ? Je ne sais pas si sur reddit ou github...

J'ai travaillé sur le développement d'ERP sous des formulaires Web Asp.net et Asp.net MVC pour deux systèmes différents, je peux dire avec confiance que travailler sur des formulaires Web est une torture, surtout lorsque vous avez une solution énorme avec une architecture médiocre, et au contraire MVC peut transformer comme par magie une architecture laide en une solution de haut niveau avec la possibilité d'organiser les couches et d'utiliser le modèle de référentiel avec un ORM fiable et puissant tel que EF.
mais honnêtement, la plupart des développeurs que j'ai rencontrés et qui se plaignent de MVC souffrent d'une expérience et d'une connaissance limitées du nouveau modèle.
Je conseille personnellement aux développeurs qui souhaitent apprendre MVC de zéro à héros d'essayer https://www.pluralsight.com au lieu de parcourir le Web et de perdre du temps et de l'argent sur des sujets controversés et des blogs sur MVC qui sont dans de nombreux cas biaisés ou médiocres. dans le cadre.

Wow, ce temps a changé les développeurs est en fait vrai. J'ai félicité Microsoft pour la simplicité et la simplicité d'EF et de MVC lorsque je les ai rencontrés pour la première fois en 2013. Comme cela a déjà été dit, la compréhension de ces frameworks ne se fait pas automatiquement ! Suivez les didacticiels, regardez quelques-unes des centaines de vidéos disponibles et réessayez. Désolé mec, mais vous développez une compréhension de ces choses au fur et à mesure que vous passez du temps avec

Je suis d'accord avec l'auteur. Pour ceux qui utilisent mvc pour la première fois. L'approche n'est pas aussi conviviale que les autres comme php, rail .. trop de concept à comprendre avant de l'utiliser. Cependant, une fois que vous avez compris le concept, mvc semble être très efficace.

Pourquoi quelqu'un détesterait-il le cadre d'entité. J'ai dû écrire pas plus de 5 requêtes SQL au cours des trois dernières années.

Bien que ce ne soit pas sorcier, à la fin il y a une certaine science derrière cela et comme pour tout, cela peut prendre du temps et des efforts pour bien comprendre, je suis avec l'auteur original, que MVC et les échantillons sont un peu écrasant lorsque vous essayez de tout comprendre en une seule séance, peut-être que s'il y avait une sorte de feuille de triche à utiliser lors de l'application de connaissances ou de concepts d'autres cadres, cela pourrait rendre l'apprentissage de MVC plus supportable pour ceux qui trouvent cela difficile.

Alors que les retours sont toujours appréciés, car si quelqu'un se plaint, c'est qu'il y a quelque chose à améliorer, par contre si vous faites une petite enquête sur les posts de l'auteur, vous constaterez qu'il est très bavard et compare beaucoup de choses à la science des fusées.

Certains échantillons:
https://github.com/dotnet/docs/issues/9115
https://github.com/dotnet/docs/issues/9299
https://github.com/dotnet/docs/issues/9274
https://github.com/dotnet/docs/issues/9234
https://github.com/MicrosoftDocs/azure-docs/issues/20313
https://github.com/dotnet/docs/issues/9396
https://github.com/aspnet/EntityFramework6/issues/671
https://github.com/aspnet/EntityFramework6/issues/686
https://github.com/twbs/bootstrap/issues/27783
https://github.com/MicrosoftDocs/visualstudio-docs/issues/2237
https://github.com/aspnet/EntityFramework.Docs/issues/1254
https://github.com/aspnet/EntityFramework.Docs/issues/1240

Même lorsque les choses ne sont pas sorcieres, elles peuvent toujours être compliquées et nécessiter de la patience pour les étudier. Lire plus sur le sujet au lieu de se plaindre que c'est trop difficile pourrait être un bon point de départ.

Il semble que vos problèmes ne concernent pas MVC, mais Entity Framework. Pour certains d'entre nous à l'aise avec l'écriture SQL, Entity Framework ajoute une couche d'abstraction indésirable. Personnellement, j'utilise Dapper, ce qui facilite grandement l'utilisation des lecteurs. Vous pouvez toujours écrire votre propre SQL. MVC est un modèle assez simple. Il devient un peu plus difficile de comprendre comment transmettre et sortir des données et comment utiliser efficacement certaines des fonctions d'assistance, mais conceptuellement, ce n'est pas difficile.

MVC ne nécessite pas l'utilisation d'EF, bien que l'authentification utilisateur intégrée l'utilise.

Amis, commentez avec aide ou positivité, mais pas avec ridicule. Le PO semble avoir des inquiétudes avec EF, et le commentaire de David est excellent. https://github.com/aspnet/AspNetCore/issues/7039#issuecomment -457869924

Issues est un endroit pour aider. Si vous voulez discuter des mérites de MVC par rapport à autre chose, essayez l'un des autres sites de plaintes populaires sur Internet.

Hé bienvenue @ LJ9999 J'aimerais que plus de gens posent des questions comme celle-ci.
Je commencerai par dire que ce n'est que mon opinion, alors n'hésitez pas à être d'accord ou en désaccord avec tout ou partie de celui-ci.

Je suis tout à fait d'accord que le développement web/logiciel est difficile. J'ai personnellement passé des années à étudier et à expérimenter pour acquérir l'expérience que j'ai. Chaque fois que je veux utiliser un nouveau framework ou une nouvelle bibliothèque, c'est toujours difficile. Cela m'oblige à passer plus de temps à apprendre et à expérimenter à nouveau pour être à l'aise et en confiance pour l'utiliser. Comme j'ai appris de plus en plus au fil des ans, je crois sincèrement que je suis devenu meilleur et plus rapide à apprendre, donc cela devient plus facile.
Au fil des ans, je pense que les défis impliqués ont changé. Certaines choses sont devenues plus faciles, mais de nouveaux défis ont également été introduits. Dans l'ensemble, cependant, je pense que c'est beaucoup plus facile maintenant que lorsque j'ai commencé. Je pense aussi que c'est une expérience moins frustrante et je trouve que c'est plus agréable.
Cela dit, je pense qu'en tant qu'industrie, nous pouvons toujours continuer à nous efforcer de nous améliorer. Je pense que ce sont des questions comme celle-ci qui mettent en lumière les défis auxquels nous sommes confrontés et inspirent la nécessité de continuer à améliorer la situation.

Je veux faire particulièrement attention à ne pas vous conseiller de choisir une solution plutôt qu'une autre car je ne pense pas qu'il y ait suffisamment d'informations pour que je le fasse.
L'un des plus grands défis que je trouve dans la résolution de problèmes est d'identifier le problème réel à résoudre. Il serait très facile de catégoriser ce problème comme nécessitant de "créer un site Web", mais avec autant de solutions parmi lesquelles choisir pour "créer un site Web", l'une d'entre elles pourrait potentiellement fonctionner. Le problème doit être décomposé autant que possible car cela fournit un critère pour évaluer les différentes solutions.
Deuxièmement, nous avons tous des préférences personnelles. Vous avez droit au vôtre, et personne ne peut vous dire ce que vous préférez ou avec lequel vous vous sentez plus à l'aise de travailler. Ceci est entièrement basé sur vous.
De plus, lorsque d'autres personnes sont impliquées, une équipe ou une entreprise, des facteurs supplémentaires peuvent devoir être pris en compte, tels que les préférences de l'équipe, ainsi que les politiques et la stratégie de l'entreprise.
Ce ne sont là que quelques-uns des facteurs impliqués qui doivent être pris en considération lors de l'évaluation de différentes solutions.

Une dernière chose que je voudrais aborder est votre message. Je pense que ce n'est pas assez précis pour comprendre ce que vous attendez d'une réponse. Dans mon interprétation, il y a beaucoup de questions différentes auxquelles vous essayez d'obtenir une réponse, ainsi que vous donnez votre avis. Celles-ci sont toutes valables et utiles, mais lorsqu'elles sont posées et soulevées ensemble dans un problème github, il est difficile de rassembler une réponse claire et concise ou d'entamer une discussion pour vous fournir les réponses que vous recherchez.
Ma suggestion pour vous serait d'essayer à nouveau et d'être plus précis avec vos questions ou opinions. Ne vous inquiétez pas d'ouvrir de nombreux problèmes, s'ils sont bien écrits et détaillés, ils seront bien mieux reçus et vous aurez beaucoup plus de chances d'obtenir des réponses à vos questions ou d'être dirigés de manière appropriée.

J'espère que cette réponse vous aidera d'une certaine manière. Sachez simplement que de nombreuses personnes sont prêtes à vous aider, mais il est de votre responsabilité de faciliter la tâche de quelqu'un pour vous aider.

@LJ9999 un commentaire (espérons-le constructif)...

À partir du SQL que vous avez publié, il est possible que vous utilisiez Entity Framework 6. Entity Framework Core (une version plus récente écrite à partir de zéro) a pour objectif explicite de générer un SQL sain et lisible qui essaie de ressembler à ce que vous écrivez vous-même - il y a de fortes chances que si vous essayez, vous verrez quelque chose de plus raisonnable - essayez-le et faites-le nous savoir.

Mes critères de résultat sont simples... Nombre de lignes de code à implémenter. Plus de code - plus de risque de bogue, une plus grande courbe d'apprentissage, plus d'heures perdues (sauf si vous êtes un entrepreneur facturant à l'heure).
J'ai vu un volume de code 8 fois plus important en faisant mvc avec le framework Javascript. Sur les pages cshtml de la vieille école. Et 5 fois plus de temps.

Méfiez-vous de ceux qui utilisent l'expression « dans le bon sens »

MVC en tant qu'architecture logicielle vous est plus utile dans ce cas.
M est le modèle, qui pourrait être votre base de données, il peut répondre aux demandes d'informations, répondre aux instructions pour modifier l'état de ses informations et même informer les observateurs des systèmes événementiels lorsque les informations changent.
V est la vue, qui fournit effectivement l'élément d'interface utilisateur de l'application. Il restituera les données du modèle sous une forme adaptée à l'interface utilisateur.
C est le contrôleur, qui reçoit les entrées de l'utilisateur et appelle les objets du modèle ou rend simplement la vue.

Votre choix de pile technologique ne signifie pas que MVC est bon ou mauvais, c'est juste une architecture logicielle.

@shanselman

Amis, commentez avec aide ou positivité, mais pas avec ridicule. Le PO semble avoir des inquiétudes avec EF, et le commentaire de David est excellent. #7039 (commentaire)

Je suis tout à fait d'accord Scott.

Il est également compréhensible que certains utilisateurs plus expérimentés se sentent fortement à propos d'un titre qui semble balayer un excellent cadre et des années de travail acharné de la part de l'équipe principale d'ASP.NET et de la communauté comme "inutilisable" dans une seule déclaration, même si c'était probablement pas l'intention. Je pense que cela a probablement causé le ridicule.

Il peut être utile de modifier le titre pour qu'il corresponde au problème réel.

Nous fermons périodiquement les problèmes de "discussion" qui n'ont pas été mis à jour depuis longtemps.

Nous nous excusons si cela cause des inconvénients. Nous vous demandons si vous rencontrez toujours un problème, veuillez enregistrer un nouveau problème avec des informations mises à jour et nous enquêterons.

Cette page vous a été utile?
0 / 5 - 0 notes