Custom MembershipProvider avec interface Web et DAL

Question

Je travaille sur une solution ASP.NET avec 2 projets. L'une est l'interface Web et l'autre contient ma logique métier. J'utilise LINQ to SQL pour mon accès aux données dans le second projet. En dehors de ma base de données, j'ai une table appelée Utilisateurs qui contient des informations sur l'utilisateur.

J'ai commencé à implémenter un MembershipProvider. Je remarque que MembershipUser est couplé avec MembershipProvider. Quelle est la manière la plus correcte d'amener mon BLL/DAL à parler des utilisateurs? Dois-je implémenter au minimum MembershipUser et chaque fois qu'un utilisateur appelle une méthode, il appellera par exemple. GetUserInfo() dans mon BLL/DAL, pour obtenir des informations complètes sur l'utilisateur?

Ou devrais-je rendre les méthodes de classe MembershipUser appel mes méthodes de classe "Utilisateurs" personnalisées (comme un wrapper) dans la BLL/DAL (cette classe d'utilisateurs personnalisés n'est pas liée à linq)?

Ou puis-je étendre d'une manière ou d'une autre la classe "CFUsers" Linq to sql pour étendre MembershipUser.

J'espère que cela a du sens.

Answer 1

Je vois généralement ceci comme une entité distincte car MembershipUser tourne autour de l'appartenance qui est une préoccupation générique et un utilisateur dans votre système tourne autour de tout ce que votre domaine implique, je vois votre point de vue où ces deux entités pourraient être contenues dans un , alors. Les profils sont définitivement la solution la plus simple.

Il y a une soluce sur les docs MSDN à http://msdn2.microsoft.com/en-us/lib...US,VS.80).aspx et une bonne procédure pas à pas de Scott Guthrie à http://weblogs.asp.net/scottgu/archi...18/427754.aspx

Comme toujours Cela dépend de vos objectifs. L'ajout au profil est un mécanisme simple pour des données supplémentaires. Il nécessite très peu de personnalisation et rend l'information facilement disponible pour l'application web. Ce n'est peut-être pas où vous voulez stocker ce type de données; sinon, c'est une non-solution.

Si cela ne correspond pas, faire un nouveau fournisseur dérivé de la valeur par défaut (à hériter de ce que vous avez déjà) est une excellente option. et bien sûr l'ultime http://codesmart.wordpress.com/2009/03/27/extending-the-microsoft-aspnet-membership-provider/