Question

Mon équipe est en train de concevoir un modèle de domaine qui dissimulera différentes sources de données derrière une abstraction de référentiel unifiée. L'un des principaux facteurs de cette approche est la très forte probabilité que ces sources de données subissent des modifications importantes dans un proche avenir. Nous ne souhaitons pas réécrire la logique métier lorsque cela se produit. Une base de données sera notre base de données d'adhésion qui a été implémentée à l'origine à l'aide du fournisseur d'adhésion ASP.Net par défaut. Le fournisseur d'appartenance est lié à l'espace de noms System.Web.Security, mais nous avons des instructions de conception qui exigent que notre couche de modèle de domaine ne dépende pas de System.Web (ou de toute autre dépendance d'implémentation / d'environnement), car elle sera utilisée dans différents environnements - nous ne voulons pas non plus que nos sites Web communiquent directement avec des bases de données.

Je réfléchis à ce qui serait une bonne approche pour réconcilier l'approche MembershipProvider avec notre architecture n-tier abstraite. Mon sentiment initial est que nous pourrions créer un " DomainMembershipProvider " qui interagit avec le modèle de domaine, puis implémente des objets dans le modèle qui traitent du référentiel et gèrent la logique de validation / de gestion. Le référentiel implémenterait alors l’accès aux données à l’aide de notre outil d’accès aux données ORM (encore indécis).

Y at-il des lacunes flagrantes dans cette approche - je n’ai pas travaillé en étroite collaboration avec la classe MembershipProvider, il se peut donc que quelque chose manque. Sinon, existe-t-il une approche qui, selon vous, répondra mieux aux exigences que j'ai décrites ci-dessus?

Merci d'avance pour vos réflexions et vos conseils.

Cordialement, Zac

Était-ce utile?

La solution

Cela fait six mois que la question a été posée et personne ne semble avoir été en mesure de fournir une réponse. Je pensais donc expliquer la solution que nous avons finalement choisie.

En gros, nous avons décidé de ne pas utiliser d'implémentation de MembershipProvider. Nous utilisons plutôt notre propre service d'adhésion personnalisé placé au sommet d'un référentiel. Il était important pour nous de maintenir la base de données existante aspnet_Membership afin que notre référentiel ait essentiellement dupliqué la fonctionnalité intégrée SQLMembershipProvider (du moins les aspects dont nous avons besoin) - initialement via Linq-to-SQL, mais nous passons maintenant à NHibernate. . Il est prévu de remplacer la base de données sur les membres d’ici un an environ lorsque tous nos sites Web auront été mis à niveau pour utiliser le nouveau modèle.

Il était possible d'utiliser un fournisseur d'appartenance personnalisé, mais il est finalement devenu évident qu'il était plus simple, plus cohérent et plus facile à gérer d'utiliser une implémentation personnalisée. Nous utilisons toujours la fonctionnalité d'authentification de formulaires intégrée pour vérifier qu'un utilisateur est connecté et rediriger les utilisateurs qui tentent d'accéder à des zones sécurisées de notre site sans être authentifiés au préalable - mais nous avons remplacé la fonctionnalité liée au fournisseur de profil. .

En fin de compte, nous estimons que si le fournisseur d’adhésion est un outil puissant et facile à utiliser au sein d’ASP.Net, s’il ne cadre pas avec l’approche plus large utilisée dans votre application, il est utile d’envisager une approche alternative.

Autres conseils

Intéressant, merci d'avoir posté votre solution finale. Je suis dans une situation similaire, mais en écrivant un Membershipprovider personnalisé. Je ne sais pas où placer le fournisseur car il a besoin d'accéder à la base de données ainsi qu'à l'espace de noms System.Web. Il semble que ce soit la seule classe qui viole toute cette séparation des préoccupations.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top