¿Cuáles son las 'grandes' ventajas de tener Poco con ORM?

Question

Una ventaja que me viene a la mente es que si usa las clases Poco para la asignación de Orm, puede cambiar fácilmente de una ORM a otra, si ambas admiten Poco.

Tener un ORM sin soporte de Poco, p. las asignaciones se hacen con atributos como DataObjects.Net Orm, no es un problema para mí, ya que también con los Orms poco soportados y sus entidades proxy generadas, debe tener en cuenta que las entidades son en realidad objetos DAO vinculados a algún contexto/sesión, p.ej la serialización es un problema, etc.

Answer 1

POCO, todo se trata de acoplamiento flexible y capacidad de prueba.

Así que cuando esté haciendo POCO puede probar su Modelo de Dominio (si está haciendo DDD, por ejemplo) de forma aislada. No tiene que preocuparse por cómo persiste. No necesita almacenar contextos/sesiones para probar su dominio.

Otra ventaja es que hay menos abstracciones con fugas. Porque las preocupaciones de persistencia no se envían a la capa de dominio. Entonces estás aplicando el principio de SRP.

La tercera ventaja que puedo ver es que al hacer POCO tu modelo de dominio es más evolutivo y flexible. Puede agregar nuevas funciones más fácilmente que si estuviese acoplado a la persistencia.

Uso POCO cuando estoy haciendo DDD, por ejemplo, pero para algún tipo de aplicación no necesita hacer DDD (si está haciendo pequeñas aplicaciones basadas en datos) por lo que las preocupaciones no son las mismas.

Espero que esto ayude

Answer 2

Ninguno. Punto. Todas las ventajas que a la gente le gusta tirar son ventajas que no son importantes en la gran escala de la imagen. Prefiero una clase base sólida para objetos de entidades que realmente contenga una gran cantidad de código integrado (como lanzar eventos de cambio de propiedad cuando las propiedades cambian) que escribir todo eso yo mismo. Tenga en cuenta que Hice una ORM (en ese momento disponible comercialmente) para .NET antes de que existieran "LINQ" u "ObjectSpaces". Utilicé mapeadores O/R como hace 15 años y nunca encontré un caso en el que POCO fuera realmente algo que valiera la pena.

Dicho esto, los atributos PUEDEN ser malos por otras razones. Prefiero el enfoque Fluent NHibernate en estos días: comencé mi propio mapeador (ahora retirado) con atributos y luego me mudé a archivos basados ​​en XML.

El tema "POCO no me sirve para nada" proviene principalmente del hecho de que las entidades SIMPLEMENTE NO SON OBJETOS NORMALES. Tienen mucha funcionalidad adicional así como limitaciones (como velocidad de consulta, etc.) que el usuario debería tener en cuenta de todos modos. Los ORM, a pesar de LINQ, no se reemplazan de todos modos, aunque si comienzas a usar sus características más interesantes. Por lo tanto, al final obtienes POCO y sigues chupando con una clase base y semántica diferente a izquierda y derecha.

Encuentro que la mayoría de los proponentes de POCO (como en: "debe tener", no "sería bueno") normalmente NO han pensado sus argumentos hasta el final real. Obtienes todo tipo de pensamientos bastante asquerosos, casi al nivel de "los procedimientos almacenados son más rápidos que el SQL dinámico", cosas que simplemente no son ciertas.Cosas como:

• "Quiero tener ellos en los casos en los que no necesitan ser salvados ot la base de datos" (utilizar una agrupación de objetos por separado, sin comprometerse),
• "Me pueden querer tener mi propia funcionalidad en una clase base (el ORM debe allos entidad abstracta clasificada sin funcionalidad, así que ponga su PROPIA clase base por debajo de la del ORM)
• "Quizás quiera reemplazar el ORM por otro" (así que nunca use una funcionalidad más alta) , espero que la API de ORM sea compatible y, de todos modos, PUEDE tener que reescribir partes grandes).

En general, las personas POCO también pasan por alto la gran cantidad de trabajo que, de hecho, es para hacerlo CORRECTO: con cosas como actualizaciones de objetos transaccionales, etc., hay una TONELADA de código en la clase base. Algunas de las interfaces .NET son horribles de implementar en un nivel POCO, aunque mucho más fácil si puede vincularse con el ORM.

tomar el puesto de Thomas Jaskula aquí:

POCO acoplamiento es todo acerca de suelta y capacidad de prueba.

¿Suponia que usted puede probar databinding sin tenerlo? La capacidad de prueba es material de framework simulado, y hay REALMENTE poderosos que incluso pueden "redirigir" llamadas a métodos.

Así que cuando usted está haciendo POCO se puede a prueba su modelo de dominio (si estás haciendo DDD por ejemplo) de forma aislada. No tiene que preocuparse de cómo se conserva . No es necesario que guarde contextos/sesiones para probar su dominio.

Realmente no es cierto. La persistencia debe ser parte de cualquier prueba de modelo de dominio, ya que el modelo de dominio está ahí para persistir. Siempre puede probar escenarios no persistentes simplemente sin comprometer los cambios, pero muchas de las pruebas implicarán persistencia y la falla de eso (es decir, facturas con datos no válidos/faltantes no válidos para escribirse en el disco, por ejemplo).

Otra ventaja es que hay abstracciones menos permeables. Debido a que problemas de persistencia no se presionan a la capa de dominio . Por lo tanto, está aplicando el principio de SRP.

Actualmente no. Un modelo de Dominio apropiado nunca tendrá métodos de persistencia en las entidades. Este es un ORM horrible para empezar (user.Save()). OTOH la clase base hará cosas como la validación (IDataErrorInfo), manejará eventos de actualización de propiedades en archivos persistentes y, en general, le ahorrará muchísimo tiempo.

Como dije antes, parte de la funcionalidad que DEBE tener es realmente difícil de implementar con variables como almacén de datos, como la capacidad de poner una entidad en un modo de actualización, hacer algunos cambios y luego retrotraerlos. No es necesario: dígale a Microsoft que lo use si está disponible en sus cuadrículas de datos (puede cambiar algunas propiedades y luego presionar Escape para deshacer los cambios).

La tercera ventaja es que puedo ver que haciendo POCO su modelo de dominio es más evolutiva y flexible.Puede agregar nuevas funciones más fácil que si fuera junto con la persistencia.

No argumento. No puede jugar agregando campos a una clase peristet sin manejar la persistencia, y puede agregar características no persistentes (métodos) a una clase no-baja igual que a una clase poco.

En general, mi clase base no POCO hizo lo siguiente:

• cambios de propiedad de la manija y IDataErrorInfo - sin que el usuario escribir una línea de código para los campos y elementos de la ORM podía manejar.
• Manejar la información del estado del objeto (Nuevo, Actualizado, etc.). Esta es información intrínseca en mi humilde opinión que también se envía a menudo a la interfaz del usuario. Tenga en cuenta que este no es un método de "guardar", sino simplemente una propiedad EntityStatus.

Y contenía una cantidad de métodos invalidables que la entidad podría usar para extender el comportamiento SIN implementar una interfaz (pública), por lo que los métodos eran realmente privados para la entidad. También tenía algunas propiedades internas más, como obtener acceso al "administrador de objetos" responsable de la entidad, que también era el punto para solicitar otras entidades (enviar consultas), que a veces era necesario.

Answer 3

El soporte POCO en un ORM tiene que ver con la separación de preocupaciones, siguiendo el Single Responsibility Principle. Con el soporte POCO, un ORM puede hablar directamente con un modelo de dominio sin la necesidad de "enturbiar" el dominio con código específico de acceso a datos. Esto garantiza que el modelo de dominio esté diseñado para resolver solo problemas relacionados con el dominio y no problemas de acceso a datos.

Además de esto, el soporte de POCO puede hacer que sea más fácil probar el comportamiento de los objetos de forma aislada, sin la necesidad de una base de datos, información de mapeo o incluso referencias a los ensamblados de ORM. La capacidad de tener objetos "independientes" puede facilitar significativamente el desarrollo, porque los objetos son fáciles de crear y de crear instancias.

Además, como los objetos POCO no están vinculados a una fuente de datos, puede tratarlos igual, independientemente de si se han cargado desde su base de datos primaria, una base de datos alternativa, un archivo plano o cualquier otro proceso. Aunque esto puede no parecer inmediatamente beneficioso, tratar sus objetos de la misma forma independientemente de la fuente puede hacer que el comportamiento sea fácil de predecir y trabajar.

Elegí NHibernate para mi ORM más reciente debido a la compatibilidad con objetos POCO, algo que maneja muy bien. Se adapta al enfoque de Diseño Dirigido por Dominio que sigue el proyecto y ha permitido una gran separación entre la base de datos y el dominio.

Poder cambiar las herramientas ORM no es un argumento real para el soporte de POCO. Aunque sus clases pueden no tener ninguna dependencia directa en el ORM, su comportamiento y forma estarán restringidos por la herramienta ORM y la base de datos a la que está mapeando. Cambiar su ORM es un cambio tan significativo como cambiar su proveedor de base de datos. Siempre habrá funciones en un ORM que no están disponibles en otro y sus clases de dominio reflejarán la disponibilidad o la ausencia de características.

En NHibernate, que están obligados a marcar todos los publicprotected o como miembros de la clase virtual para habilitar el soporte para perezosos de carga. Esta restricción, aunque no ha cambiado significativamente mi capa de dominio, tiene tuvo un impacto en su diseño.