È buona pratica aggiungere metodi ai POCO o creare classi separate per aggiornare i valori dei POCO?

Question

È buona pratica aggiungere metodi ai POCO o creare classi separate per aggiornare i valori delle POCO nel caso in cui ne abbiamo bisogno?

Ad esempio,

public class ForUser 
{ 
    [Required] 
    public int Depratment { get; set; } 

    public List<SelectListItem> DepartmentsList { get; set; } 

    [Required] 
    public int Role { get; set; } 

    [Required] 
    [StringLength(200, MinimumLength = 3, ErrorMessage = "Length Of The First Name Should Be More Than Three Letters")] 
    public string FirstName { get; set; } 

    [StringLength(200, MinimumLength = 3, ErrorMessage = "Length Of The Mid Name Should Be More Than Three Letters")] 
    public string MidName { get; set; } 

    [Required] 
    [StringLength(200, MinimumLength = 3, ErrorMessage = "Length Of The Last Name Should Be More Than Three Letters")] 
    public string LastName { get; set; } 

    [Required] 
    [EmailAddress(ErrorMessage = "Invalid Email Address")] 
    public string Email { get; set; } 

    [StringLength(14, MinimumLength = 10 , ErrorMessage = "Length Of The Mid Name Should Be More Than Nine Letters and Less than fourteen Letters")] 
    [RegularExpression(@"^[+]?[0-9]*", ErrorMessage="Phone Number is not correct")] 
    public string PhoneNumber { get; set; } 

    [Required] 
    public string Password { get; set; } 


    public int UserId { get; set; } 
    public int Company { get; set; } 
    public int Country { get; set; } 
    public List<SelectListItem> Roles { get; set; } 
} 

lo uso solo per contenere i dati per aggiornare i model entity o per restituire i dati alla vista. A volte ho bisogno di aggiornare alcune proprietà prima di inviare lo object alla vista, come l'elenco chiamato Roles nell'esempio precedente, quindi mi chiedo se dovrei aggiungere i metodi alla classe POCO o è meglio creare una classe per aggiornare le proprietà?

Answer 1

Here troverete una risposta alla tua domanda:

A POCO non è un DTO. POCO sta per Plain Old CLR Object, o Plain Old C# Object. È fondamentalmente la versione .Net di un POJO, Plain Old Oggetto Java. Un POCO è il tuo oggetto aziendale. Dispone di dati, validazione e qualsiasi altra logica aziendale che si desidera inserire in lì. Ma c'è una cosa che un POCO non ha, ed è quello che lo rende un POCO. I POCO non hanno metodi di persistenza. Se hai un POCO di tipo Person, non puoi avere un metodo Person.GetPersonById(), o un metodo Person.Save(). I POCO contengono solo dati e logica di dominio, , nessuna logica di persistenza di alcun tipo. Il termine che ascolterai per questo concetto di è Persistenza Ignoranza (PI). POCOs sono Persistenza Ignorante.

preferisco leggere l'intero articolo, non solo per ottenere la risposta alla tua domanda, ma anche capire la differenza tra il POCO e DTO.

Answer 2

La classe sembra più una specifica di dati, quindi dovrebbe rimanere tale. Separare il comportamento dal modello in questo caso.

Answer 3

In tal caso, il POCO ha un ruolo ViewModel e, come tale, IMHO, dovrebbe essere solo un DTO (Data Transfer Object) e avere solo il codice minimo.

Potrebbe essere alcuni metodi di convalida, può essere un calcolo di base tra le proprietà e dovrebbe essere.

Answer 4

Questo problema è ciò che viene utilizzato per risolvere DCI, separando i semplici oggetti POCO/dati dalla funzionalità.

Se i dati verranno aggiornati in qualche tipo di processo come descritto, in DCI si modella tale processo come un contesto, basato su un modello mentale dell'utente, non su un'astrazione come un servizio, facciata o qualsiasi altro modello di progettazione dell'ingegnere che disconnette in modo efficace l'utente dal sistema e diffonde le funzionalità effettive attraverso il sistema.

vostri pocos (ciò che il sistema è ) dovrebbero essere magra, la funzionalità (ciò che il sistema fa) dovrebbe contenere ciò che è necessario per i vostri Pocos di interagire. Se ti sforzi di mantenerlo così semplice, sarai in grado di fare a meno delle infinite astrazioni e limitazioni di ciò che oggi viene chiamato OO, ma in realtà è un orientamento di classe, creando così tanti problemi nella progettazione del software. Persino il polimorfismo (GOTO di oggi) scomparirà, rendendo il comportamento del sistema di prima classe.

Answer 5

//In my EnityModels folder is where I keep my POCO classes 
//Nice and clean class 
public class Model 
{ 
    public int ModelID { get; set; } 
    public string ModelName { get; set; } 
    public int ModelSSN {get; set; } 
    public virtual ICollection<Language> Languages { get; set; } 
} 

/*Then in another folder called ModelVMs you would have your ViewModels 
    ViewModels are usually not mapped to the Database 
    I like to have a Constructor that does the data transfer for me 

    This is also where I keep my methods as well as my property validation 
    FYI: I also keep Flags and View Specific Properties in my ViewModel*/ 

public class ModelVM //or ModelViewModel 
{ 
    public ModelVM() { } 

    public ModelVM(Model model) 
    { 
     this.ModelVMID = model.ModelID; //yes the "this" in this example is unnecessary 
     this.ModelVMName = model.ModelName; 
     this.ModelVMSSN = model.ModelSSN; 

     foreach(var lang in model.Languages) 
     { 
      this.SLLanguages.Add(new SelectListItem() 
            { 
             Text = lang.LanguageName, 
             Value = lang.LanguageID 
            } 
           ); 
     } 
    } 

    [Required] 
    public int ModelVMID {get; set; } 
    [Required] 
    [Display(Name="Model Name")] 
    public string ModelVMName {get; set; } 
    [Required] 
    [Display(Name="We need your Social Security Number")] 
    public int ModelSSN {get; set; } 

/****************View Specific Properties****************************/ 
public SelectList SLLanguages { get; set; } 
}