Programmazione .NET e classi POCO

Come ha detto Wyatt, POCO e POJO non implicano assolutamente alcun metodo. Penso che ciò derivi dal non sapere cosa sia non-POCO e non-POJO.

Le prime versioni delle tecnologie ORM non erano POCO e POJO semplicemente perché richiedeva alle entità di ereditare alcune classi base dal framework stesso. In caso di Java, Entity Beans. In caso di Entity Framework, POCO non era possibile nella prima versione e ogni entità doveva ereditare Entity base class.

Questo requisito ha creato dipendenza del modello dati sulla tecnologia di persistenza, che rende molte cose difficili o impossibili. Cose come l'unità di test del modello richiedono di prendere in giro la struttura del bean / entità che si è dimostrata 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 nell'ambiente mobile.

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

Quello di cui stai parlando probabilmente si chiude su Modello di dominio anemico rispetto al modello di dominio appropriato.

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 associazione automatica MVC che riguardano principalmente le proprietà e ignorano i metodi.

La persistenza incorporata negli oggetti del modello viola la separazione delle preoccupazioni e rende molto difficile fare cose come testare gli oggetti senza mettere in piedi 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.

link

Ho utilizzato Metodi di estensione per cose come questa ultimamente.

Il POCO contiene una logica che ha senso solo per l'oggetto stesso. La logica aziendale o logica coordinata dell'oggetto va in un'estensione BL. L'accesso ai dati può essere effettuato 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 bel myObject.PriceInCart() e myObject.Save() mantenendo la tua classe focalizzata sui dati. Ovviamente per i metodi statici devi avere MyAppDA.Create() invece di MyApp.Create() .