Classes de programação .NET e POCO

Eu estava pensando hoje à noite enquanto refletia sobre algum aplicativo que eu precisava mudar e isso me fez pensar. Entity Framework Entidades são POCO (Plain CLR Objects antigos) e os modelos usados ​​no ASP.NET MVC geralmente também são POCO. Isso basicamente significa apenas propriedades, sem métodos.

Agora, a programação OO normalmente permite que um objeto encapsule sua funcionalidade, que inclui suas propriedades e métodos, permitindo que o polimorfismo aconteça. Com o aumento das classes POCO sendo usadas, padrões de design como repositórios genéricos se tornaram mais populares. Quando, no passado, meus objetos tinham suas próprias operações CRUD, agora as tenho em um repositório.

É apenas uma evolução no OO em que as operações CRUD são removidas dos objetos para permitir que sejam dissociadas ou talvez as operações CRUD não devessem estar no nível do objeto no passado e eu estava errado? diabos, talvez ambos sejam perfeitamente legítimos e sempre foram. É apenas uma observação que me fez pensar, então pensei em procurar outras opiniões.

Como Wyatt disse, POCO e POJO de forma alguma implicam em métodos. Eu acho que isso decorre de não saber o que não é POCO e não é POJO.

As primeiras versões das tecnologias ORM não eram o POCO e o POJO simplesmente porque exigiam que as entidades herdassem alguma classe base da própria estrutura. No caso do Java, Entity Beans. No caso do Entity Framework, o POCO não era possível na primeira versão e cada entidade era obrigada a herdar a Entityclasse base.

Esse requisito criou dependência do seu modelo de dados na tecnologia de persistência, o que dificulta ou impossibilita muitas coisas. Coisas como o teste de unidade do modelo requerem zombaria da estrutura do bean / entidade, que provou ser praticamente impossível. Você também não pode usar o modelo com tecnologia de persistência diferente ou não pode usá-lo em diferentes contextos, como no ambiente móvel.

Portanto, sua suposição de que o POCO é sobre a inexistência de métodos está errada. O POCO é sobre poder usar o modelo em separação da sua tecnologia de persistência.

O que você está falando provavelmente se aproxima do Modelo de Domínio Anêmico versus o modelo de domínio adequado.

O POCO de forma alguma implica que não existem métodos - embora a maioria dos exemplos que se vê use muitos dos recursos de ligação automática do MVC, que lidam principalmente com propriedades e ignoram métodos.

A persistência incorporada nos objetos do modelo viola a separação de preocupações e dificulta a execução de testes de unidade, sem levantar um banco de dados. Não é uma função do objeto de modelo, mas uma função se uma classe diferente, como um repositório.

Apenas duas abordagens diferentes, cada uma com seus próprios méritos.

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

Ultimamente, tenho usado métodos de extensão para coisas como essa.

O POCO contém lógica que só faz sentido para o próprio objeto. Lógica comercial ou lógica de objeto coordenado entra em uma extensão BL. O acesso a dados pode ir para uma camada de acesso a dados ou uma extensão de acesso a dados.

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)
        {
            …
        }
    }
}

Isso proporciona uma ótima experiência myObject.PriceInCart()e, myObject.Save()ao mesmo tempo, mantém sua classe focada nos dados. Claro que para métodos estáticos você precisa ter em MyAppDA.Create()vez de MyApp.Create().