MVC, WCF, EF, LINQ - Est-ce juste moi? [fermé]

17

... ou les choses se compliquent-elles?

Il me semble que vous devez connaître beaucoup de choses pour développer «correctement» une application Web MS ces jours-ci. Dans le mauvais vieux temps où nous ne savions pas mieux, nous avions des tables de base de données, ASP.NET, ADO.NET et vous avez construit une application web en utilisant des concepts relativement simples.

Ces jours-ci, il semble y avoir beaucoup de cadre pour «vous aider» à le faire «correctement», mais je ne suis pas convaincu que cela rend tout plus facile et meilleur. J'ai le sentiment que je serai dans une assez petite minorité avec ce sentiment, mais y a-t-il quelqu'un d'autre qui pense que les choses sont devenues un peu folles?

wcf linq mvc entity-framework Compagnon
la source
MVC = ASP.Net, WCF = Services Web + .Net Remoting, EF = ADO.Net, Linq remplace certaines boucles foreach. Il existe désormais autant de frameworks qu'auparavant.
vortexwolf
John, je dois être «en partie» d'accord avec vous. Je suis en train de perfectionner mes compétences .Net, certainement beaucoup plus à parcourir qu'il y a 5 ans.
TeaDrinkingGeek
Bien qu'il puisse y avoir beaucoup de technologies DB dans l'arène MS, cette question est vraiment hors sujet sur ce site. Il ne pose pas vraiment de question et tombe carrément dans le "... suce, ai-je raison?" catégorie coup de gueule répertoriée dans la FAQ
Walter

Réponses:

17

Toutes ces choses sont facultatives, utilisez-les si elles sont utiles, pas si elles ne le sont pas. C'est aussi simple que ça. Vous pouvez certainement écrire de bonnes applications Web correctes sans aucun de ces acronymes dans votre solution.

Personnellement, j'ai tendance à trouver MVC comme un framework assez léger et facile à utiliser (beaucoup plus facile à démarrer que les formulaires Web, imo). De même, LINQ fournit un moyen courant d'interroger n'importe quoi; bien aussi. EF et WCF et moi avons eu nos désaccords, mais quand c'est le cas, je ne les utilise pas.

Paul
la source
2
+1 sur «utilisez-les s'ils sont utiles». J'essaie d'utiliser la règle, j'essaye de faire 1 nouvelle «chose» dans chaque projet. Après un certain temps, vous aurez de l'expérience avec beaucoup de choses et vous verrez que les choses deviennent plus faciles à mesure que vous les utilisez.
Jan_V
+1 à vous également pour «essayez de faire 1 nouvelle chose sur chaque projet». J'aime apprendre et grandir aussi.
Paul
1
J'essaie de faire 1 nouvelle chose sur chaque projet, mais c'est généralement parce que la nouvelle chose que j'ai apprise le dernier projet est maintenant obsolète :)
gbjbaanb
9

Non, pas vraiment. LINQ est la plus grande chose depuis le pain en tranches lors de l'interaction avec une base de données.

Ce que vous devez retenir, c'est que ces choses sont construites sur d'autres choses. LINQ n'ajoute pas au nombre de choses que vous devez savoir pour développer un site Web ASP.NET, car vous n'avez plus besoin de connaître SQL. Et LINQ est OO, ce qui est beaucoup plus conforme au développement régulier d'applications, ce qui en fait un shitton complet plus facile à faire que SQL, et beaucoup plus facile à intégrer avec C #.

Si vous ne pensez pas que LINQ est plus facile que SQL, vous devriez peut-être publier quelques exemples de quelque chose de plus difficile dans les nouveaux paradigmes.

Plus important encore, les sites Web avaient auparavant beaucoup moins de fonctionnalités. Comment allez-vous créer de nouveaux sites Web qui fonctionnent mieux, évoluent mieux et offrent de nouvelles fonctions dans le même code?

DeadMG
la source
4
Une jointure gauche dans LINQ est plus difficile que dans SQL. De plus, si vous essayez de résoudre les problèmes de base de données, vous devrez de toute façon regarder SQL. De plus, connaître SQL vous aidera si vous souhaitez passer à une plate-forme de développement non Microsoft.
btilly
10
Aucun framework ORM n'est aussi puissant que SQL. Il y a des requêtes que je dois effectuer qui sont presque impossibles à faire dans un cadre ORM.
bit-twiddler
1
@ bit-twiddler> oui, et c'est pourquoi la plupart des frameworks ORM vous permettent également d'exécuter du SQL brut (ou des sprocs). Vous pouvez demander à un bon gars C # d'écrire la plupart des requêtes pour les piétons, et les experts DB comme vous peuvent regrouper les éléments difficiles pour eux dans un sproc ou une vue.
Paul
1
Alors que je conçois des bases de données à grande échelle et écris une tonne de SQL côté client et côté serveur, je ne suis pas un DBA. Je suis un ingénieur logiciel. Je n'ai jamais travaillé nulle part où les développeurs de logiciels étaient uni-qualifiés. Chaque jour, je peux écrire du code en C, C ++, Java, Object Pascal, PL / SQL ou langage assembleur Intel (je ne compte pas HMTL, XML et CSS comme langages de programmation car ils ne sont pas Turing Complete). Je gère également mes propres ensembles d'outils et un environnement de test basé sur Tomcat (chaque membre de mon équipe a son propre serveur Tomcat).
bit-twiddler
1
Ecrire LINQ pour interagir avec une base de données (LINQ-to-SQL, LINQ-to-Entities) sans connaître SQL ...? Recette pour un désastre.
Kirk Broadhurst
3

Si les anciens concepts que vous avez mentionnés ne fonctionnaient plus, je conviendrais que ce serait fou, mais les nouveaux cadres sont des alternatives. Une acceptation aveugle serait folle. Vous devez justifier. Personnellement, SQL en soi n'est pas un problème pour moi. En essayant d'ajouter certaines des fonctionnalités des sites Web modernes, les formulaires Web ne les coupent plus.

Je suis sûr que certaines personnes ASP classiques ressentaient la même chose à propos de .NET, mais peu peuvent continuer à faire valoir cet argument. Je construis quelques sites en ASP classique et je n'y retournerais pas.

JeffO
la source
2

"Est devenu un peu fou". C'est exactement la façon dont je décrirais une DataSetsolution ADO.NET, ASP.NET. :)

Je suis d'accord qu'il y a beaucoup plus à apprendre, mais chacun des cadres que vous mentionnez a amélioré le développement .NET.


la source
0

Je dirais que c'est un problème mondial qui peut affecter à peu près tous les frameworks ou plateformes (développeurs). Lorsque le nouveau cadre est publié, il semble généralement petit et compact, mais au fil du temps et de nouvelles fonctionnalités / fonctionnalités / API sont incluses (soit par feuille de route / demande, nouveaux concepts / tendances / technologies ou simplement par évolution), il devient "gonflé". Vous avez commencé avec "une façon de faire les choses" et maintenant il y a plus de possibilités parmi lesquelles vous pouvez choisir (et - vous ne savez pas / n'êtes pas sûr - laquelle choisir). Apprendre de nouvelles choses peut prendre du temps, mais elles peuvent vous offrir des solutions beaucoup plus flexibles / plus rapides / meilleures aux mêmes problèmes qui étaient auparavant résolus par un ensemble limité d'options.

Une fois, je suis tombé sur une citation amusante - "tout le code se transforme en s #! T avec suffisamment de temps et de mains" - qui à mon humble avis résume pourquoi de nouvelles choses dans les cadres existants devraient émerger pour mettre de nouvelles idées en action et faire évoluer.

yojimbo87
la source