MembershipProvider personalizado con la interfaz web y DAL

Question

Estoy trabajando en una solución ASP.NET con 2 proyectos. Una de ellas es la interfaz web y la otra contiene mi lógica de negocio. Estoy usando LINQ to SQL para mi acceso a datos en el segundo proyecto.

Además de mi base de datos, tengo una tabla llamada Usuarios que mantiene la información del usuario.

He empezado a poner en práctica un MembershipProvider. Me he dado cuenta de que MembershipUser se acopla con MembershipProvider. ¿Cuál es la forma más correcta de conseguir mi BLL / DAL hablar de Usuarios? Debería aplicar mínimamente MembershipUser y cada vez que un usuario llama a un método, que llamaré por ejemplo. GetUserInfo () en mi BLL / DAL, para obtener información completa sobre el usuario?

O debería hacer que los métodos de la clase MembershipUser llaman mis personalizados "Usuarios" métodos de clase (como un envoltorio) en el BLL / DAL (esta clase de usuarios personalizados no está relacionado con LINQ)?

O ¿hay algún modo extender la clase LINQ a SQL "CFUsers" extender MembershipUser.

Espero que esto tenga sentido.

Answer 1

Por lo general veo esto unas entidades separadas como MembershipUser gira en torno a la membresía que es una preocupación genérica y un usuario en el sistema gira en torno a lo que su dominio implica, yo veo su punto de vista en que ambas entidades podrían estar contenidos en uno, entonces. Perfiles es sin duda la forma más fácil de seguir.

Hay una walkthough en la documentación de MSDN en http://msdn2.microsoft.com /en-us/lib...US,VS.80).aspx y una buen tutorial de Scott Guthrie en http://weblogs.asp.net/scottgu/archi. ..18 / 427754.aspx

Como siempre Depende de cuáles son sus objetivos. Agregando a perfil es un mecanismo sencillo para obtener datos adicionales. Se requiere muy poco en el camino de la personalización y hace que la información fácilmente disponible para la aplicación web. Esto puede no ser en la que desea almacenar este tipo de datos; si no, es un no-solución.

Si esto no se ajusta, por lo que un nuevo proveedor derivada del defecto (a heredar lo que ya tiene) es una gran opción. y por supuesto la última http: // codesmart.wordpress.com/2009/03/27/extending-the-microsoft-aspnet-membership-provider/