Estoy usando Entity Framework O/R mapper de Microsoft y el uso de clases de entidad (clases generadas que se asignan a objetos DB) como objetos comerciales. ¿Esto está bien? Por favor, declare sus contras o pros. ¿Qué hacer en un caso de comunicación WCF entre la capa empresarial y la presentación, cómo enviar esos objetos como miembros de datos?¿Usar entidades de Entity Framework como objetos comerciales?
Estoy usando EF de esta manera y una buena característica es que las entidades generadas son clases parciales, lo que les permite extenderse de una manera bastante protegida de los problemas de regeneración.
También consulte this link on MSDN que describe algunos escenarios de uso común con EF en lo que respecta a la lógica de negocios.
Entity framework fue diseñado para los objetos de entidad que se utilizarán como objetos de negocios, pero debe tener en cuenta que los objetos comerciales estarán vinculados a la tecnología O/R y al modelo EDM. En EF 1.0, no hubo ningún soporte para persistence-ignorance escenarios, pero se agregó soporte en 4.0. Puede implementar interfaces, si no desea utilizar ninguna de sus clases base.
A partir de .NET 3.5 SP1, también deben ser utilizables como parámetros y tipos de devolución en los métodos de servicio WCF sin ningún código adicional.
Actualización: Hay soporte para ignorancia de persistencia en Entity Framework 4.0/.NET 4.0 –
En mi experiencia, hemos utilizado objetos EF en la capa empresarial de nuestra aplicación, pero cuando hacemos la transición a la capa de presentación a través de nuestra capa de servicios WCF, crearemos objetos de visualización a partir de los objetos EF.
En nuestro caso, solo la vista se pasa a la capa de presentación. Hacemos esto para controlar cómo se presentan los datos y aplicar una validación defensiva para los datos que ingresan desde la capa de presentación.
En el caso de que haya objetos EF en la transacción WCF, perderá el contexto del objeto al que se asoció el objeto EF. Hay algunos esfuerzos en CodePlex que intentan ayudar con esto, pero no he continuado con sus esfuerzos.
¿No puede simplemente volver a adjuntar los objetos si pierden su contexto de objeto original? Sin embargo, necesitaría manejar problemas de concurrencia.
No recomendaría el uso de objetos EF como objetos DataContract para WCF, ya que vincularía fuertemente su implementación de objetos de entidad a clientes de servicios web, el cambio será difícil de hacer en el futuro, más difícil será el número de clientes plan de tener.
dos limitaciones a tener en cuenta de que se han topado son:
heredados Los objetos pueden no tener propiedades de navegación - es decir, si tiene una clase de "persona" y luego un "cliente" y "proveedor" esos clientes y proveedores no pueden tener propiedades de navegación.
Los métodos y los campos calculados (cualquier cosa en las clases parciales) no se transmiten a través de ADO.Net Data Services; si también está utilizando ADO.Net Data Services, cualquier cosa que expanda los objetos de Entity Framework en clases parciales no será transmitido a través de ADO.Net Data Services.
Estos generalmente no son artículos show-tapón (para propiedades de navegación simplemente no utilizar la herencia en marco de la entidad, por ahora), pero podría ser algo de interés para usted mismo.Estoy esperando que una versión futura permita estos dos elementos.
La aplicación de ejemplo BookLibrary WPF Application Framework (WAF) muestra cómo se puede utilizar el patrón Model-View-ViewModel (MVVM) en combinación con Entity Framework.
En primer lugar, con 11k puntos de vista de la pregunta en el momento de escribir estas líneas, estoy un poco sorprendido por la falta de respuestas y con el debido respeto, la calidad de las respuestas, una pregunta bastante simple.
Así que, ahora que he desahogado un poco, me gustaría abordar esta (s) pregunta (s) porque creo que se aplica aún más hoy con el reciente lanzamiento de Entity Framework Code-First.
"¿Cómo utilizar entidades de Entity Framework como objetos comerciales?"
un par de puntos de aclaración antes de empezar:
Cuando dice "objetos de negocio", estoy bajo la impresión de que estos objetos se refieren a contener reglas o que van desde la lógica, por ejemplo, validación simple (es decir, campos obligatorios) a una lógica más compleja (es decir, procesamiento de impuestos en un proceso de pago).
No creo que pueda responder a su pregunta de seguimiento con respecto a WCF. La razón de esto es simplemente porque voy a responder objetivamente a sus preguntas sobre EF como objetos comerciales que luego me obligarían subjetivamente a adoptar una posición que demostrara ser contradictoria con mi intento de responder de manera genuina y objetiva a la primera pregunta.
Dicho esto, en su EF como objetos de negocio preguntas ...
"Estoy usando Entity Framework O/R asignador de Microsoft y usando entidad clases (clases que son generados asignado a objetos DB) como objetos comerciales . ¿Esto está bien?
Lo sentimos, simplemente no hay una respuesta correcta o incorrecta aquí. Depende de cuál sea su objetivo y cuál sea su conclusión, que es el diseño más razonable, al mismo tiempo que comprende las ventajas y desventajas de hacerlo.
“Por favor, indique sus desventajas o ventajas”
que bueno que lo preguntas! Estaré encantado de responder y mi esperanza es que, teniendo en cuenta los pros y los contras, pueda tomar una decisión informada sobre si cree o no que usar EF para sus objetos comerciales es "correcto". Típicamente, explico los pros y los contras haciendo que sea fácil de "digerir", sin embargo, no creo que sea apropiado aquí porque creo que estaríamos haciendo una injusticia a un tema tan interesante que también está cerca. y querido para mi corazón
En primer lugar, permítanme hablar técnicamente por un momento ... Puede utilizar objetos EF como objetos comerciales, técnicamente no hay nada que le impida hacerlo. Como cuestión de hecho, EF Code-First (CF) hace que esto sea increíblemente fácil al permitirle crear POCO y darle la posibilidad de aplicar anotaciones de datos para una validación simple, así como implementar IValidatableObject para una validación más compleja.Genial, ¿eh?
Ahí radica el corazón de la discusión.
EF, o cualquier ORM, está diseñado para admitir la gestión de datos. Su principal responsabilidad son los datos y, por lo tanto, los objetos que crea son datos centrados. Entonces, si también estás tratando de diseñar tus objetos por comportamiento, entonces tienes un pequeño enigma a la mano. En pocas palabras, este enigma se llama desajuste de impedancia. Imagínate esto; Tiene dos casos de uso requeridas en su aplicación:
Si se utiliza EF (cualquier sabor) , o cualquier ORM para el caso, puede orientarse hacia el uso del mismo objeto "Usuario" para manejar la capacidad de salvar a un usuario, así como a buscar un usuario para extraer el subconjunto de campos de solo lectura. Es probable que lo que para una de varias razones:
Hay ventajas y desventajas de hacerlo y se podía ver esto es una forma positiva o negativa dependiendo de tu opinión.
Supongo que si usted cree en la normalización del código sobre el comportamiento que ha tenido éxito en gran medida. Pudo limitar la cantidad de código, lo que podría ahorrarle tiempo, al escribir un solo objeto para manejar sus datos y casos de uso comercial para esa entidad.
Y supongo que si usted cree en la normalización del comportamiento sobre el código que ha fallado miserablemente. Al guardar el código, ha sacrificado el diseño de objetos por sus responsabilidades, lo que puede dificultar su administración y, por consiguiente, aumentar el costo de mantenimiento.
Independientemente de su opinión, probablemente todos estemos de acuerdo en que este objeto comercial ha asumido múltiples responsabilidades y el comportamiento (¡no datos!) Del objeto es secundario en el mejor de los casos. Su principal responsabilidad es la gestión de los datos y sus responsabilidades secundarias son el procesamiento de las reglas de negocio, ambos simples & complejos, relacionados con la edición de un usuario y la visualización de la información de usuario de solo lectura. En el diseño orientado a objetos (OOD), si el diseño de un objeto se caracteriza por su identidad y comportamiento, entonces este objeto puede ser un individuo confuso ya que no se adhiere a la definición misma de OOD.
Algo a considerar desde un punto de vista técnico, cada vez que solicita el objeto del usuario, hereda una cantidad importante de sobrecarga. Esto puede incluir elementos tales como todas las propiedades y reglas comerciales cuando solo se muestra un subconjunto de información de solo lectura.
Entonces, ¿qué tiene que ver todo esto con si debo usar o no EF para representar mis objetos comerciales?
Bueno ... Si bien es técnicamente posible, existen filosofías diferentes (algunas buenas, otras malas) sobre si debe o no usar EF, o cualquier ORM, para representar sus objetos comerciales. Di una sinopsis dirigida al corazón de estas filosofías anteriores, pero están documentadas con mucho más detalle por individuos como Rocky Lhotka y Martin Fowler.
La dirección que tome dependerá de la aplicación y, desde una perspectiva filosófica, puede depender de cuán idealista o pragmático sea. Dicho esto, no estoy implicando que ser idealista o pragmático se relacione con el uso de EF para objetos comerciales o no, simplemente tendrá un impacto en su opinión sobre esto.
En el momento de redactar este informe, las indicaciones de Microsoft son que EF está diseñado para manejar la lógica empresarial y, correcto o incorrecto, parece que se mueven más en esa dirección. EF siempre está evolucionando y se están eliminando ciertas limitaciones técnicas, de modo que EF puede eventualmente ser utilizado para satisfacer lo mejor de ambos mundos. En otras palabras, eventualmente puedes tener tu pastel y comértelo también.
Espero que esto ayude.
Desactivado para responder a una pregunta sobre si la ignorancia de persistencia con un ORM es ridícula teniendo en cuenta que el objetivo es administrar los datos. :-) Lo siento, no pude resistir!
+1: hago esto también, y todavía no he encontrado un caso que me haya atascado. Muestro mis propiedades de clase de entidad en diagramas, listas y etiquetas en una aplicación winform. – Marcel
Gracias por el enlace. –