entidades de Entity Framework POCO en la aplicación web de varias capas

Question

Soy nuevo en EF4 y no he tenido ninguna experiencia con él antes. Entonces, desnudo conmigo si esta es una pregunta muy simple. Tengo mis entidades POCO (archivo .tt) en BOL, el archivo .edmx (EDM) en DAL y mi aplicación web en la capa Presentación. Toda la lógica de negocios va a la capa BLL. Estas son las referencias:

UI -> BLL-CHA-BOL
BLL -> DAL-BOL
DAL -> BOL
BOL -> Ninguno de mi proyecto.

1- ¿Es correcto mi entendimiento de la distinción de capas? ¿Estoy en la dirección correcta? 2- ¿Cómo puedo usar el proveedor de membresía ASP.NET con entidades? ¿Debo implementar membresía, persistencia ignorante también y asignar todas las tablas de usuario en el servidor sql a las entidades?

2- ¿Cómo puedo agregar una validación personalizada? No me refiero a maxlength o correo electrónico válido ..., me refiero a algo así como niveles de acceso. Por ejemplo, quiero que ciertos usuarios puedan modificar un campo (por ejemplo, precio del producto) en mi sitio web. ¿Dónde debería usar el método User.IsInRole? el BLL no tiene ninguna referencia a la información del usuario. ¿Debo pasar algunos parámetros a BLL (como "bool CanChangePrice") para aclarar los niveles de acceso?

Answer 1

Wow Kamyar, solo algunas preguntas envueltas en esta ;-) No estoy seguro si cubriré todo el terreno posible, pero aquí va.

ProjectStructure
- en general, la estructura de los proyectos es correcta, y las referencias que tengo son correctos. Algunos pueden argumentar que desea separar sus preocupaciones un poco y romper algunas de las referencias, pero personalmente encuentro que su estructura es factible.

• Como una cuestión práctica tiendo a mantener mi EDXM y POCO en el mismo proyecto. Solo tengo una carpeta Entidades que contiene EDXM y Model.Context.tt, una carpeta POCO para Model.tt y mi POCO virtual (a continuación), y una carpeta Repository para mi repositorio & unidad de trabajo.

• También creo un archivo llamado VirtualPOCOs que es una clase parcial vinculada a las POCO generadas por sus T4. Mis diseños tienden a estar estrechamente vinculados a la estructura de la base de datos. Los VirtualPOCO me dan un poco de flexibilidad para desviarme del diseño de DB en esas situaciones puntuales. Aquí no entra mucho, solo esas pocas necesidades muy específicas que todo proyecto parece tener.

• Es posible que también desee considerar un repositorio, una puerta de enlace de datos de tabla o una configuración de registro activo. Todos estos patrones probablemente se combinarán con una Unidad de trabajo. Hay toneladas de patrones de diseño y sus necesidades o preferencias pueden empujarlo hacia uno u otro. El punto aquí es proteger las capas superiores del acceso directo al contexto EF4. De esta forma puede centralizar la gestión de transacciones de la conexión & y asegurarse de que las capas superiores solo utilicen POCO y no retengan accidentalmente los objetos linq-to-sql.

proveedor de suscripciones
Hay una duda un cisma entre el MembershipProvider y EF. Sin embargo, puede descargar el código fuente de SQLMembershipProvider y convertirlo para usar EF. De hecho, hice esta conversión. El archivo tiene aproximadamente 1500 líneas de longitud, pero no tiene una gran cantidad de código ADO.

Lo que no preguntó, pero creo que debería abordar, es si desea utilizar el proveedor de Membresía. Si realiza funciones y funciones básicas de membresía, el proveedor de Membresía, Roles y Perfil puede ahorrarle mucho tiempo. Para un recorrido en profundidad de las capacidades, revisa la serie en 4GuysFromRolla (http://www.4guysfromrolla.com/articles/120705-1.aspx).

Si sus necesidades son más complejas, entonces, en mi humilde opinión, el proveedor de membresía se descompone con bastante rapidez. Por ejemplo, cuando un usuario se registra para su sitio, inmediatamente debe crear filas en un puñado de tablas diferentes. Bueno, el proveedor de membresía se registra a través de webconfig y utiliza la interfaz de proveedor de membresía. Solo acepta ciertos campos en la función de creación. Entonces, ¿qué es un niño para hacer? Bueno, puede abrir una transacción a mayor escala en su controlador, ejecutar los proveedores de membresía agregar función de usuario, ejecutar su propio MyCustomUserStuff(), luego confirmar la transacción. Dos razones por las que esto me parece poco atractivo son que ahora tengo código transaccional subiendo en mi pila de llamadas y si todo lo que tengo que hacer es agregar algunos campos adicionales, ahora he duplicado innecesariamente mis llamadas a la base de datos.

Supongo que acabo de encontrar que el proveedor de membresía es bastante restrictivo, y una vez que ingresé y creé mi propio proveedor de membresía personalizado, los beneficios de usar el modelo de MS cayeron rápidamente.

Validación
creo que la respuesta es un rotundo --que depende. ¿Sus permisos son bastante estáticos? es decir, aquellos en el grupo "SiteManagers" pueden editar todo el sitio? ¿O sus permisos son mucho más finos? Significado SiteManagers tiene acceso a estos 75 campos repartidos en estas 22 tablas, ¿o está más basado en tablas? Además, ¿qué tan mutables son los permisos? ¿El administrador de su sitio debe poder activar/desactivar el acceso con frecuencia o desactivarlo en varios campos en diferentes tablas?

Creo que necesito saber más sobre sus requisitos para una respuesta específica. Tenga en cuenta que cuanto más fino sea el tamaño de sus permisos, mayor será el dolor de cabeza de configuración que el cliente tendrá conocimiento de & administrando todos los permisos.

Además, ¿qué back-end está utilizando? Muchos DBA enfrentan estas decisiones. Una estrategia de uso frecuente en ese mundo es crear una serie de vistas donde cada vista expone las columnas que tienen los usuarios. Por ejemplo, la vista EmployeesHR expondría solo aquellas columnas a las que los recursos humanos tienen acceso, y el EmployeeDirectory expondría jsut los campos a los que tiene acceso el directorio. A continuación, los usuarios de recursos humanos reciben permiso para la vista de recursos humanos, pero no la tabla subyacente. Solo un pensamiento.

De todos modos, espero que esto ayude.

Answer 2

1- Tu distinción de las capas me parece correcta. No haría referencia al DAL en la interfaz de usuario, ya que en mis proyectos, prefiero que solo la capa intermedia acceda al DAL. Pero no está mal. Entonces pareces en la dirección correcta.

2 - Que yo sepa, no hay un MembershipProvider que funcione con EF. Así
en proyectos en los que hemos utilizado afiliación, esto es lo que hicimos:

• creado las tablas de configuración con el aspnet_regsql.exe
• la Web.Config utilizar el SqlMembershiptProvider
• añadido en la cadena de conexión web.config OTRO (uno para Membresía y otro para EF)
• Construyó el archivo EDMX con todas las tablas, incluidas las de Membresía.

En el código, un UserManager/RoleManager (BLL o DAL que depende de su arquitectura) obtener las informaciones utilizando métodos estándar de membresía. Y siempre use los objetos de Membresía, no los de EF. De hecho, la parte de gestión de usuario/roles está separada de la EF.

se utilizan exclusivamente aspnet_* entidades EF cuando hay una relación entre las tablas personalizadas y una mesa de afiliación (por ejemplo, cuando se quiere vincular a uno de su tabla con la tabla aspnet_Users mantener una referencia del usuario que introduce un dato).

3- Para la gestión correcta, utilizaría un BLL RightManager que permitiría a la IU saber si el usuario puede cambiar el campo (para poder desactivarlo o impedir la entrada) y utilizar esta información en su método de validación
En mi proyecto utilizo una tabla Right y asocio un Derecho con un Rol.En el RightManager, proporcione un método RequestRight(Right).
Si su gestión correcta es demasiado simple para crear tablas, simplemente use User.IsInRole() en su RightManager (así que lo usaría en BLL).
Colocaría el método de validación en la UI si es "básico" y en el BLL si contiene reglas más complejas (que involucran el acceso DAL, por ejemplo).

Answer 3

sobre EF & membresía que sé, usted no necesita utilizar cualquier proveedor dB en lugar de proveedor de pertenencia pero si lo desea, puede asignar tablas de miembros de la FE y crear método adicional para proveedor común