En el acceso a datos separado y la capa de lógica de negocios, ¿puedo usar las clases de Entity Framework en la capa empresarial?

Question

En el acceso a datos por separado & capa de lógica de negocios, ¿puedo usar las clases de Entity Framework en la capa de negocios?

EDITAR: No creo que necesite cambiar la capa de acceso a datos de mi lógica empresarial en el futuro (es decir, será SQL Server), sin embargo, lo haré para la capa de interfaz de usuario. Por lo tanto, la pregunta es más importante: ¿hay algún problema importante con el uso de clases de EF para mí en la capa de negocios? Parece que habría menos código de plomería.

Answer 1

Por lo general, el enfoque de "mejores prácticas" sería algo como esto:

• en su capa de datos, usted tiene entidades EF que se cargan desde y almacenan de nuevo a la base de datos

• en En la capa Business, tiene sus propios objetos de dominio (simplemente clases C#) que representan los datos en los que su aplicación necesita trabajar. Esos pueden ser más o menos idénticos a una entidad de capa de datos, o pueden contener varias entidades "atómicas" para formar un objeto comercial, o pueden ser muy diferentes. Para aliviar la necesidad de muchas instrucciones de asignación izquierda-derecha-derecha (para mover los valores de las propiedades hacia adelante y hacia atrás entre las entidades de la capa de datos y los objetos de la capa de negocios), debería revisar las herramientas como AutoMapper que hacen que sea realmente fácil establecer hasta "asignaciones" entre tipos de objetos similares y le permite asignar fácilmente los tipos de ida y vuelta

• la capa de interfaz de usuario (s) luego visualizar y representar objetos de la capa de negocios para el usuario para obtener información y/o manipulación

La ventaja es que su modelo de dominio de capa empresarial representa los objetos comerciales reales con los que está trabajando, y se vuelve más o menos independiente de cómo esos re realmente almacenado en la capa de datos. Además, esto evita "pegar" su capa de interfaz de usuario a una tecnología de acceso a datos en particular.

Por supuesto - que es la mejor práctica recomendada para una aplicación a escala empresarial, donde es posible que tenga que cambiar la capa de acceso de datos, etc. Para una aplicación más simple, es posible que no pase por esos prácticas, saber lo que está haciendo, y que te estás "enganchando" a ti mismo en EF si utilizas entidades EF a lo largo de toda la capa de negocios en la interfaz de usuario. Si eso está bien con usted y su escenario de aplicación, no hay una razón en particular para no hacerlo. Las entidades EF son clases de objetos .NET perfectamente válidas: simplemente derivan de una clase base común (EntityObject en lugar de object) y tienen una cierta cantidad de "equipaje" que aparece. Pero no hay nada que te impida usar esas entidades de EF en toda tu aplicación.

Answer 2

Como con todas las preguntas de esta naturaleza, la respuesta es que depende. Si quiere una separación clara de su lógica de acceso a datos y su capa de negocios, diría que no. Si eso es lo que pretendes, utilizaría un patrón de depósito e IoC para construir la capa de acceso a datos, luego puedes intercambiar un stub de prueba para pruebas de unidad y luego acceder a la base de datos cuando llegues a la prueba funcional.

Answer 3

Si necesita poder cambiar la forma en que accede a la base de datos sin tener que volver a escribir con mucho código, es mejor que mantenga EF fuera de la capa empresarial. Puede usar la unidad de trabajo y los patrones de repositorio para lograr esto; acceder a toda la funcionalidad del nivel de datos a través de las interfaces. Si suelta EF, las interfaces siguen siendo las mismas, solo cambia las clases de implementación.

Sin embargo, existen argumentos para no usar UoW ​​y repositorio, el principal es que el DbContext ya le proporciona muchas de esas características.

Inicié un proyecto con un UoI y un repositorio en la capa de datos y sin referencias EF en la capa empresarial. A medida que progresé, sentí que solo estaba haciendo un trabajo para mí y los dejé caer. En cambio, utilizo el acceso al contexto desde el nivel comercial, realizo cualquier conversión que necesito desde DTO hasta el nivel comercial POCO.

En mi situación, estoy seguro de seguir con EF. Si no lo eres, considera qué enfoque te conviene.