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.
definitivamente ayudó mucho. Gracias. – Kamyar