ASP.NET MVC/ASP.NET Application d'accès aux données WebForm - quelle est la meilleure architecture?

Question

En réponse à une answer posté par Marc Gravell et sa suggestion par courriel, je me demandais:

Quels sont les choix que les gens font au moment de décider de leur architecture pour un nouveau projet?

---

Cette question pourrait servir de point de référence décent pour les liens/idées/suggestions/décisions d'architecture, quelque chose de vraiment qui est d'intérêt pour décider de la meilleure façon d'aborder une nouvelle solution.

Je travaille actuellement sur une application ASP.NET MVC - principalement comme un exercice pour augmenter mon expérience du nouveau framework - qui fonctionne avec une interface frontale ExtJs transmettant des objets Json entre les couches.

La testabilité est très importante. Ma couche .NET utilise des interfaces pour définir des contrats. Elle comprend une couche de service qui gère la validation des données et la logique d'application qui interagit avec la couche de stockage. Tout ce qui me permet de tester assez complètement. J'ai une hiérarchie de modèle personnalisée qui est basée sur la base de données, mais elle n'est liée à aucun outil ORM (j'utilise LinqToSql à l'heure actuelle) liant à une plate-forme particulière. Mes référentiels renvoient mes modèles personnalisés et non leurs propres structures de base de données, ce qui, je l'espère, me permettra de développer différentes implémentations de référentiel à l'avenir sans trop de problèmes. Une autre raison de cette approche était que je travaille avec une base de données héritée qui a des choix de conception intéressants et qui ne peut pas trop changer la structure pour le moment, je voulais donc un peu plus de contrôle sur les modèles résultants.

---

Tout cela peut sembler tout à fait tort de certains d'entre vous me dire si ce que vous pensez;)

Answer 1

On dirait que vous êtes sur la bonne voie. Personnellement, dans les incarnations actuelles, je choisirais toujours MVC sur des formulaires Web. Les formulaires Web font trop abstraction du modèle sous-jacent et je trouve que c'est généralement plus difficile que cela en vaut la peine. Ce n'est que si vous pouvez prédire en toute sécurité que vous pouvez coller au modèle que les formulaires Web ont été conçus pour gérer, travailler selon le modèle standard, et que vous vous souciez peu de la testabilité, est-ce que je recommanderais des formulaires Web. Le seul autre scénario où les formulaires Web pourraient avoir du sens est si vous avez une équipe de personnes fortement ancrée dans cette technologie et qui souhaite rester en ligne avec les piles d'applications existantes. Même alors, pour la croissance de vos développeurs et la maintenance à long terme du produit (post-transition), je recommande encore MVC si vous pouvez le swing. Cela dit, Microsoft continuera probablement à supporter le modèle de formulaires web pendant un certain temps et les deux modèles deviendront probablement de plus en plus faciles à brancher et à jouer ou à échanger entre eux (d'après les conversations que j'ai eues avec un couple des responsables de programme de l'équipe ASP.NET).

Answer 2

tout en étant séduisant au premier abord, pour moi, les formulaires Web deviennent difficiles à gérer à mesure que l'application se développe. Avec MVC, les relations sont plus naturelles et compatibles avec les idéaux.