Programación .NET y clases POCO

Estaba pensando esta noche mientras reflexionaba sobre alguna aplicación que necesito cambiar y me hizo pensar. Entity Framework Las entidades son POCO (objetos CLR simples y antiguos) y los modelos utilizados en ASP.NET MVC también suelen ser POCO. Esto básicamente significa solo propiedades, no métodos.

Ahora, la programación OO normalmente permite que un objeto encapsule su funcionalidad, que incluye sus propiedades y sus métodos, esto permite que ocurra el polimorfismo. Con el aumento de las clases de POCO que se utilizan, los patrones de diseño, como los repositorios genéricos, se han vuelto más populares. Cuando en el pasado mis objetos habrían tenido sus propias operaciones CRUD, ahora los tengo en un repositorio.

¿Es esto solo una evolución en OO donde las operaciones CRUD se eliminan de los objetos para permitir que se desacoplen o tal vez las operaciones CRUD no deberían haber estado a nivel de objeto en el pasado y yo estaba equivocado? diablos, tal vez ambos son perfectamente legítimos y siempre lo han sido. Es solo una observación que me hizo pensar, así que pensé que buscaría otras opiniones.

Como dijo Wyatt, POCO y POJO de ninguna manera implican ningún método. Creo que eso se deriva de no saber qué es no POCO y no POJO.

Las primeras versiones de las tecnologías ORM no eran POCO y POJO simplemente porque requería que las entidades heredaran alguna clase base del propio marco. En el caso de Java, Entity Beans. En el caso de Entity Framework, POCO no era posible en la primera versión y cada entidad debía heredar la Entityclase base.

Este requisito creó dependencia de su modelo de datos de la tecnología de persistencia, lo que hace que muchas cosas sean difíciles o imposibles. Cosas como la prueba unitaria del modelo requiere burlarse del marco de bean / entidad que resultó ser prácticamente imposible. Tampoco puede usar el modelo con tecnología de persistencia diferente o no puede usar el modelo en un contexto diferente, como en un entorno móvil.

Por lo tanto, su suposición de que POCO se trata de la inexistencia de métodos es incorrecta. POCO se trata de poder usar el modelo separado de su tecnología de persistencia.

De lo que está hablando es que probablemente se cierra al modelo de dominio anémico frente al modelo de dominio adecuado.

POCO de ninguna manera implica que no hay métodos, aunque la mayoría de los ejemplos que se ven usan muchas de las características de enlace automático de MVC que tratan principalmente con propiedades e ignoran métodos.

Tener persistencia incrustada en los objetos de su modelo viola la separación de las preocupaciones y hace que sea muy difícil hacer cosas como probar los objetos sin poner una base de datos. No es una función del objeto modelo, sino una función si una clase diferente, como un repositorio.

Solo dos enfoques diferentes, cada uno con sus propios méritos.

/programming/1519669/data-access-layer-or-having-object-with-crud-methods

He estado usando métodos de extensión para cosas como esta últimamente.

El POCO contiene lógica que solo tiene sentido para el objeto mismo. La lógica de negocios o la lógica de objetos coordinados entra en una extensión BL. El acceso a datos puede ir a una capa de acceso a datos o a una extensión de acceso a datos.

namespace MyApp
{
    public class MyClass
    {
        public string id;
        public string name;
        public int quantity;
        public decimal price;
    }   
}

namespace MyAppBL
{
    public static class MyClassBL
    {
        public static decimal PriceInCart(this MyClass myObject)
        {
            return myObject.quantity > 10 ? myObject.price * 0.9m : myObject.price;
        }
    }
}

namespace MyAppDA
{
    public static class MyClassDA
    {
        public static void Create()
        {
            …
        }

        public static void Read(string myObject)
        {
            …
        }

        public static void Update(this MyClass myObject)
        {
            …
        }

        public static void Delete(this MyClass myObject)
        {
            …
        }
    }
}

Esto le da un aspecto muy agradable myObject.PriceInCart()y, myObject.Save()al mismo tiempo, mantiene su clase centrada en los datos. Por supuesto, para los métodos estáticos que necesita tener en MyAppDA.Create()lugar de MyApp.Create().