Uso de Entity Framework como capa de acceso a datos

Question

En mi aplicación ASP.NET quiero implementar por capa de acceso a datos usando Entity framweok para que pueda usarlo como una herramienta ORM. Pero no quiero que al resto de la aplicación le importe que la estoy usando o que esté contaminada por algo específico de la estructura de la entidad.

Parece que no puedo encontrar a nadie que esté utilizando el marco de entidades exclusivamente en su capa de acceso a los datos, así que estoy ansioso por ver ejemplos en línea de esta/experiencia que las personas tengan.

Answer 1

http://ayende.com/Blog/archive/2007/06/08/Rhino-Commons-RepositoryltTgt-and-Unit-Of-Work.aspx

Mire el ejemplo anterior, se puede aplicar el marco entidad de la misma manera con el patrón repositorio

Answer 2

Usted podría abstraer el marco de la entidad de usar algo como el patrón de repositorio como ScottGu hace con LINQ en el Serie NerdDinner.

http://nerddinnerbook.s3.amazonaws.com/Part3.htm

Answer 3

http://blog.keithpatton.com/2009/05/30/Entity+Framework+POCO+Repository+Using+Visual+Studio+2010+Net+40+Beta+1.aspx

esto se inspiró la arquitectura DDD yo sólo he trabajado con v4 EF que utiliza la Unidad COI para inyectar un repositorio de EF, espero que ayude

Answer 4

he utilizado Entity Framework como el acceso a los datos en mis dos últimos proyectos. Estos son proyectos grandes (para mí al menos) con varias cientos de tablas, 5-15 desarrolladores que duran más de un año.

En ambos proyectos tenemos una interfaz WCF en nuestra capa de servicio. No queríamos usar los objetos de Entity Framework en nuestros contratos de WCF. Por lo tanto, creamos Objetos de transferencia de datos, y mapeamos entre los objetos de DTO y Entity Framework.

Esto rompe las dependencias y mantiene los contratos lo más estables posible, pero crea un trabajo adicional.

Dependiendo de su horizonte temporal, lo haría así o usaría los objetos POCO en la próxima versión, como mencionó Kieth.

Answer 5

El EF o cualquier otro ORM (es decir, NHibernate) no reemplaza su capa de acceso a datos. Más bien, el ORM es una capa de abstracción del DAL a la fuente de datos.

No se deje engañar por creer que el EF elimina el DAL. El EF es solo otro marco de fuente de datos. Sin embargo, en la práctica recomendada, aún desea abstraer y centralizar todo el acceso (lectura/escritura) en un DAL común.

Aquí hay un ejemplo perfecto de lo que estoy hablando. Supongamos que debe eliminar un usuario determinado en uno de sus casos de uso. Sin embargo, al eliminar al usuario, es posible que desee eliminar otros registros asociados al usuario eliminado para evitar registros huérfanos (para ser honesto, utilizaría un procedimiento almacenado para esto). Ahora este caso de uso está atascado en un BO que es muy específico para este caso de uso y eliminarlo ya que el usuario es solo una parte del caso de uso total.

En algún momento, tiene un desarrollador al que se le pide que incorpore un caso de uso diferente que involucra la eliminación de un usuario. El desarrollador puede hacer algunas cosas. 1) Podría crear un nuevo caso de uso que ahora implica eliminar un usuario, pero se olvidó de borrar los registros asociados a ese usuario. 2) Pudo haber notado el caso de uso anterior pero no pudo usarlo directamente sin generalizarlo para su caso de uso, por lo que decidió copiar parte de ese caso de uso que borra apropiadamente a un usuario y sus registros asociados, en su caso de uso . Ahora tenemos partes duplicadas del código que hacen prácticamente lo mismo: eliminar un usuario. ¡Yuk! Ahora, habiendo puesto este 'usuario eliminador' digamos un DAL.Clase de ayuda para usuarios, evitas esta mala práctica de diseño.

De todos modos, lo bueno de EF, reduce el número de entidades comerciales que solía crear manualmente y proporciona una vista diferente de los datos desde un nivel de aplicación que lo que se ve en el almacén de datos.