Programmazione .NET e classi POCO

Stasera stavo pensando mentre riflettevo su qualche applicazione che ho bisogno di cambiare e mi ha fatto pensare. Entity Framework Le entità sono POCO (semplici oggetti CLR vecchi) e i modelli utilizzati in ASP.NET MVC sono in genere anche POCO. Questo in pratica significa solo proprietà, nessun metodo.

Ora la programmazione OO normalmente consente a un oggetto di incapsulare la sua funzionalità, che include le sue proprietà e i suoi metodi, ciò consente al polimorfismo di accadere. Con l'ascesa delle classi POCO utilizzate, i modelli di progettazione come i repository generici sono diventati più popolari. Quando in passato i miei oggetti avrebbero avuto le loro operazioni CRUD, ora le ho su un repository.

È solo un'evoluzione di OO in cui le operazioni CRUD vengono rimosse dagli oggetti per consentire loro di essere disaccoppiate o forse le operazioni CRUD non avrebbero dovuto essere a livello di oggetto in passato e io mi sbagliavo? diamine, forse entrambi sono perfettamente legittimi e lo sono sempre stati. È solo un'osservazione che mi ha fatto pensare, quindi ho pensato che avrei cercato altre opinioni.

Come ha detto Wyatt, POCO e POJO non implicano in alcun modo alcun metodo. Penso che derivi dal non sapere cosa sia il non POCO e il non POJO.

Le prime versioni delle tecnologie ORM non erano POCO e POJO semplicemente perché richiedevano alle entità di ereditare una classe base dal framework stesso. Nel caso di Java, Entity Beans. Nel caso di Entity Framework, POCO non era possibile nella primissima versione e ogni entità doveva ereditare la Entityclasse base.

Questo requisito ha creato dipendenza dal modello di dati dalla tecnologia di persistenza, il che rende molte cose difficili o impossibili. Cose come il test unitario del modello richiedono di deridere il framework bean / entità che si è rivelato praticamente impossibile. Inoltre, non è possibile utilizzare il modello con tecnologia di persistenza diversa o non è possibile utilizzare il modello in un contesto diverso, ad esempio in un ambiente mobile.

Quindi la tua supposizione che il POCO riguardi la non esistenza di metodi è sbagliata. POCO riguarda la possibilità di utilizzare il modello in modo separato dalla sua tecnologia di persistenza.

Quello di cui stai parlando è probabilmente la chiusura di Anemic Domain Model rispetto al modello di dominio corretto.

POCO non implica in alcun modo che non ci siano metodi, anche se la maggior parte degli esempi che si vedono utilizzano gran parte delle funzionalità di auto binding MVC che trattano principalmente di proprietà e ignorano i metodi.

La presenza di persistenza incorporata negli oggetti modello viola la separazione delle preoccupazioni e rende molto difficile eseguire operazioni come test unitari degli oggetti senza l'archiviazione di un database. Non è una funzione dell'oggetto modello ma una funzione se una classe diversa come un repository.

Solo due approcci diversi ciascuno con i propri meriti.

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

Ultimamente ho usato i metodi di estensione per cose come questa.

Il POCO contiene una logica che ha senso solo per l'oggetto stesso. La logica aziendale o la logica degli oggetti coordinati vanno in un'estensione BL. L'accesso ai dati può andare in un livello di accesso ai dati o in un'estensione di accesso ai dati.

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

Questo ti dà un aspetto molto piacevole myObject.PriceInCart()e myObject.Save()pur mantenendo la tua classe focalizzata sui dati. Ovviamente per i metodi statici devi avere MyAppDA.Create()invece di MyApp.Create().