POCO, comportamento e Igance di Peristance

Question

Da quelle che ho letto le classi POCO dovrebbero essere ignoranti di persistenza e non dovrebbero contenere riferimenti a repository.

Q1. Considerato quanto sopra, come compilare la raccolta QuestionBlocks? Ho letto che i POCO dovrebbero contenere comportamenti in modo da non terminare con un modello anemico, quindi sono un po 'confuso su come si dovrebbe farlo senza persistenza. Se è così, che tipo di comportamento metteresti in un POCO?

Es:

public class Survey 
    { 
     public int SurveyId { get; set; } 
     public string Title { get; set; } 
     public int BrandId { get; set; } 
     public DateTime Created { get; set; } 
     public List<SurveyQuestionBlock> QuestionBlocks { get; set; } 

     [ResultColumn] 
     public string Name { get; set; } 


     /// <summary> 
     /// Constructor 
     /// </summary> 
     public Survey() 
     { 
      Created = DateTime.Now; 
      QuestionBlocks = new List<SurveyQuestionBlock>(); 
     } 
    } 

Answer 1

luce di quanto sopra, come faccio a popolare l'insieme QuestionBlocks?

Durante la lettura da un database, l'infrastruttura di persistenza deve compilare la raccolta QuestionBlocks - Ricostituzione. La ricostruzione non dovrebbe richiamare il comportamento, dovrebbe solo impostare campi appropriati sul POCO. Questa è la responsabilità del repository. Un repository viene tipicamente referenziato da un servizio applicativo, che imposta lo stage per il richiamo del comportamento dell'entità.

Se è questo il caso, che tipo di comportamento inseriresti in un POCO?

Il comportamento nell'entità POCO dovrebbe riguardare le modifiche all'entità stessa e il mantenimento degli invarianti, ovvero garantire l'integrità dell'entità. Nel tuo esempio, il tipo più semplice di comportamento sul POCO dovrebbe essere il metodo per aggiungere un nuovo blocco di domande alla raccolta nel sondaggio. Idealmente, si dovrebbe fare molte delle proprietà sull'entità sondaggio di sola lettura:

public class Survey 
    { 
     public int SurveyId { get; private set; } 
     public string Title { get; private set; } 
     public int BrandId { get; private set; } 
     public DateTime Created { get; private set; } 
     public IList<SurveyQuestionBlock> QuestionBlocks { get; private set; } 
     public string Name { get; private set; } 

     public void AddQuestionBlock(string questionBlockInfo) 
     { 
      this.QuestionBlocks.Add(new SurveyQuestionBlock(...)); 
     } 

     public Survey() 
     { 
      Created = DateTime.Now; 
      QuestionBlocks = new List<SurveyQuestionBlock>(); 
     } 
    } 

Lo strato di persistenza dovrebbe essere in grado di impostare i valori delle proprietà di sola lettura attraverso la riflessione. Puoi fare un ulteriore passo avanti e solo esporre la raccolta dei blocchi di domande come raccolta di sola lettura per assicurarti che possa essere modificata solo dall'entità stessa.

Answer 2

Aggiungerei un'altra vista: POCO indica gli oggetti che non dipendono da alcun framework. La definizione wiki di un POJO è molto più significativo per me, allora quella per POCO:

• http://en.wikipedia.org/wiki/Plain_Old_Java_Object

per parafrasare la definizione wiki del POJO, possiamo dire che oggetto POCO potrebbe non essere costretto a:

I. Estendere classe pre-specificato:

public class MyClass : AnyFramework.ObjectBase {... 

II. Implementare interfacce prespecificati

public class MyClass : AnyFramework.IHaveDependency {... 

III.Contenere prespecificate attributo

[AnyFramework.KeyAttribute] 
public class MyClass {... 

Dato questo (quasi tutto il resto è consentito) nel senso di prendersi cura sullo stato dell'oggetto. Altre parole, se l'oggetto sarà verificare la logica aziendale, è corretto.

Ma qualsiasi oggetto POCO può essere utilizzato in un quadro. Oggi è principalmente per ORM che è responsabile per la persistenza. Tutti i livelli di applicazione funzionano con oggetti POCO, mentre il livello dati è responsabile del caricamento e della persistenza (CRUD). Questo è per lo più fatto tramite Proxy di questi oggetti POCO.

Quindi, POCO potrebbe essere utilizzato come oggetto business completo, che può prendersi cura di se stesso (verificare la correttezza degli elementi di raccolta, proprietà ...). Questo lo rende diverso da DTO