Meilleure architecture pour l'application ASP.NET WebForms

J'ai écrit un portail ASP.NET WebForms pour un client. Le projet a en quelque sorte évolué au lieu d'être correctement planifié et structuré depuis le début. Par conséquent, tout le code est écrasé dans le même projet et sans aucune couche. Le client est maintenant satisfait de la fonctionnalité, je voudrais donc refactoriser le code de telle sorte que je serai confiant quant à la publication du projet. Comme il semble y avoir de nombreuses façons différentes de concevoir l'architecture, j'aimerais avoir quelques opinions sur la meilleure approche à adopter.

FONCTIONNALITÉ

Le portail permet aux administrateurs de configurer des modèles HTML. D'autres "partenaires" associés pourront afficher ces modèles en ajoutant du code IFrame à leur site. Dans ces modèles, les clients peuvent enregistrer et acheter des produits. Une API a été implémentée à l'aide de WCF permettant également aux entreprises externes de s'interfacer avec le système. Une section Admin permet aux administrateurs de configurer diverses fonctionnalités et d'afficher les rapports pour chaque partenaire. Le système envoie des factures et des notifications par e-mail aux clients.

ARCHITECTURE ACTUELLE

Il utilise actuellement EF4 pour lire / écrire dans la base de données. Les objets EF sont utilisés directement dans les fichiers aspx. Cela a facilité un développement rapide pendant que j'écrivais le site, mais il est probablement inacceptable de le garder comme ça car il associe étroitement la base de données avec l'interface utilisateur. Une logique métier spécifique a été ajoutée aux classes partielles des objets EF.

DES QUESTIONS

Le refactoring aura pour objectif de rendre le site évolutif, facile à maintenir et sécurisé.

1. Quel type d'architecture serait le mieux pour cela? Veuillez décrire ce qui devrait être dans chaque couche, si je dois utiliser le modèle DTO / POCO / Active Record, etc.

2. Existe-t-il un moyen robuste de générer automatiquement des DTO / BO pour que toutes les améliorations futures soient simples à implémenter malgré les couches supplémentaires?

3. Serait-il avantageux de convertir le projet de WebForms en MVC?

Le modèle ASP.NET MVP est la meilleure architecture pour une application de formulaires Web ASP.NET à long terme . Il entre en jeu avec le concept de "séparation des préoccupations", qui est de facto une tendance derrière les modèles MV *.

La question de savoir pourquoi l' utiliser? - traité en détail dans cet article - ASP.NET MVP

• Premiers pas avec le test d'une application Webforms ASP.NET
• Compromis entre MVP et MVC
• Fin de la confusion: MVP vs MVC

1. Utilisez un modèle MVP pour séparer la logique et l'interface utilisateur, donc à l'avenir, vous pouvez passer à une technologie d'interface utilisateur différente en réutilisant la logique existante
2. Utilisez le modèle de référentiel entre BL et DAL afin de pouvoir passer à n'importe quel RDBS en réutilisant la logique métier
3. apporter des couches séparées (Dll) pour BO et DAL, ce qui minimise la maintenance.

Comme ElYusubov l'a mentionné, le modèle MVP peut être excellent.

Le concept clé est de retirer la plupart ou la totalité de votre logique du code-behind. La logique ne doit pas être liée à une page. Et si vous avez besoin de réutiliser la logique d'une page dans une autre? Vous serez tenté de copier-coller. Si vous faites cela, votre projet deviendra maintenable.

Donc, pour commencer, commencez à refactoriser votre logique hors du code et à la placer dans une couche métier. Si vous avez réussi à extraire toute la logique du code-behind, vous pouvez implémenter les interfaces nécessaires pour être un vrai MVP.

Assurez-vous également que votre accès aux données est distinct de votre logique métier. Créez une couche de données et commencez également la refactorisation à cette fin. Puisque vous utilisez EF4, cela pose moins de problème car EF devrait déjà avoir cette extrémité distincte. Vous devriez pouvoir déplacer facilement tous vos fichiers EF vers un autre projet et simplement ajouter une référence aux projets qui en ont besoin. L'avantage supplémentaire étant que vous devrez peut-être référencer votre modèle de données dans d'autres projets.

Pour éviter d'être submergé, refactorisez un peu à la fois. Chaque fois que vous touchez un morceau de code, pensez à refactoriser le code qui l'entoure. Si vous faites cela, au fil du temps, votre projet peut devenir plus maintenable.

Éditer

Vous avez demandé à ce que le code derrière hérite d'une classe de logique métier. Cela ne peut pas être fait car le code derrière la page "is-a". C # n'autorise pas l'héritage multiple, donc la classe code-behind ne peut pas être à la fois une page et un objet personnalisé. Vous devez séparer conceptuellement la logique. C'est probablement le cas que le code dans votre code-back fait beaucoup de choses différentes. Une classe doit faire une chose et une seule chose. Essayez de réfléchir à la façon dont vous pouvez conceptuellement retirer les fonctionnalités existantes. Par exemple, supposons que vous ayez une page d'inscription et que vous collectiez des informations utilisateur. Vous avez probablement un bouton appelé Register et un événement Click associé à ce bouton. Dans ce cas, vous enregistrez les informations utilisateur et effectuez le traitement dont vous avez besoin. Vous pouvez créer un objet Registration pour gérer toute cette logique.

Non seulement cette séparation est plus nette, mais elle peut également être un moyen d'auto-documenter votre code. Lorsque quelqu'un lit votre code, il vous voit appeler un objet Registration afin que vous sachiez exactement ce qui se passe.

Si vous vouliez suivre strictement le modèle MVP, au lieu de passer les paramètres à l'objet Registration, le code-behind implémenterait une interface. L'implémentation de l'interface mapperait essentiellement tous les objets de vue (champ de texte, etc.) à l'interface. par exemple chaîne publique FirstName {get {return txtFirstName.Text; }}

Une fois cela fait, vous pouvez passer la page à l'objet Regisration

Registration.RegisterUser (this);

Et cette méthode RegisterUser prend l'interface comme paramètre

public bool RegisterUser (utilisateur IUser) {user.FirstName ...}

interface publique IUser {chaîne publique FirstName; }

Si ce MVP semble déroutant, concentrez-vous simplement sur la refactorisation et sachez que tout cela est de maximiser la réutilisation du code. Il n'y a plus de raison de se répéter. C'est le principal SEC .