Qual è il vantaggio di avere modelli POCO puri?

12

Qual è il principale vantaggio dell'utilizzo di modelli POCO puri? Ho capito che i modelli dovrebbero essere semplici e puliti, ma tendo a mantenere la manutenzione degli oggetti figlio all'interno delle classi del modello. Ad esempio, se ho un ClassA e ClassB definito come segue:

public class ClassA
{
    public string MyProp { get; set; }
    public IEnumerable<ClassB> Children { get; }

    public void AddChild(ClassB newChild) { /*... */ }
    public void RemoveChild(ClassB child) { /* ... */ }
}

public class ClassB
{
    public string SomeProp { get; set; }
} 

C'è qualcosa di intrinsecamente sbagliato nell'avere i metodi di aggiunta e rimozione? Dovrei invece semplicemente esporre l'elenco e consentire al codice client di aggiungere qualsiasi cosa che passa la responsabilità di convalide di dati semplici come non null, e non duplicare su un'altra classe?

Qualsiasi aiuto è apprezzato. Grazie.

    
posta Jesse 05.06.2017 - 05:42
fonte

3 risposte

37

Le tue due domande non sono correlate.

What is the benefit to having pure POCO models?

Un POCO puro non dipende da qualche framework, convenzione, [] cosa, o intimamente connesso ad alcuni oggetti che sono similarmente dipendenti. In altre parole, il mondo può cambiare completamente attorno a un POCO e continua a fare quello che fa senza preoccuparsi. Non puoi romperlo aggiornando un framework, spostandolo in un nuovo sistema o guardandolo in modo divertente. Continua a funzionare. Le uniche dipendenze sono le cose che richiede esplicitamente.

POCO non è altro che l'idea del POJO. Il J è stato cambiato in C perché le persone ti guardano in modo strano quando spieghi un concetto che ha Java nel suo nome se quelle persone stanno usando C #. L'idea non dipende dalla lingua. Potevano semplicemente chiamarlo Plain Old Objects. Ma chi vuole vantarsi di usare POO?

Lascio che Fowler spieghi le origini:

The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.

martinfowler.com : POJO

Come per la tua altra domanda:

Is there something inherently wrong with having the add and remove methods?

Non mi piace A sapere direttamente su B . Ma questo è un DIP cosa non un POJO cosa.

    
risposta data 05.06.2017 - 06:44
fonte
3

Con Aggiungi e rimuovi stai implementando le funzioni Collection<T> . Chiediti perché stai utilizzando IEnumerable<T> invece di List<T> o qualche altra classe mutevole? Apparentemente non è perché la tua collezione dovrebbe essere in sola lettura.

L'unica ragione per cui posso pensare è che vuoi controllare quali metodi di accesso vuoi pubblicare. In tal caso sarebbe meglio creare la tua classe di raccolta, incapsulare un elenco, implementare i tuoi metodi di selezione Aggiungi e Rimuovi e implementa IEnumerable<T> . Quindi usa quello invece di IEnumerable<T> per il tipo della tua collezione di bambini.

Ma mi sembra che List<ClassB> probabilmente ti servirà bene.

    
risposta data 05.06.2017 - 09:00
fonte
0

Che cosa aggiunge AddChild a e RemoveChild rimuovi da? Se proviene dal database (o da un archivio di persistenza di qualsiasi tipo), hai ottenuto un record attivo. Non è necessariamente sempre una cosa negativa, ma sicuramente ti avvicina a dovermi preoccupare di framework, convenzioni, dipendenze, ecc., Come menziona @CandiedOrange.

Allo stesso tempo, quale sarebbe il punto di evitare una dipendenza da ClassA a ClassB (o almeno InterfaceB) se sono tutti nella stessa applicazione? Nel dominio del mondo reale che la tua applicazione sta modellando, le cose dipendono l'una dall'altra. Gli oggetti del mondo reale do hanno raccolte di altri oggetti che "appartengono" a loro. È del tutto appropriato rappresentare tali relazioni nel codice.

L'unica ragione per cui diventa persino un po 'complicato è perché sembra che tu abbia la necessità di gestire esattamente come un ClassB viene associato e dissociato da ClassA. Quindi hai un piccolo comportamento da implementare. Puoi implementarlo all'interno della classe (che è totalmente "legale", vedi link ), oppure puoi avere qualche tipo di una classe separata che contiene quel comportamento. Fai ciò che ha più senso per le tue circostanze personali.

In ogni caso, POJO / POCO è in realtà solo OOP come doveva essere, senza fronzoli e senza ostacoli. Segui i principi OOP e sarai al sicuro.

    
risposta data 05.06.2017 - 17:10
fonte

Leggi altre domande sui tag