tupla - que es tuple c#

¿Es una buena práctica agregar métodos a los POCO o crear una clase separada para actualizar los valores de los POCO?

Question

¿Es una buena práctica agregar métodos a los POCO o crear una clase separada para actualizar los valores de los POCO en caso de que lo necesitemos?

Por ejemplo,

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 para guardar los datos para actualizar la model entity o para devolver los datos a la vista. A veces necesito actualizar algunas propiedades antes de enviar el object a la vista, como la lista llamada Roles en el ejemplo anterior, así que me pregunto si debo agregar los métodos a la clase POCO o es mejor crear una clase para actualizar las propiedades?

Answer 1

En ese caso, el POCO tiene un rol de ViewModel y, como tal, IMHO, debería ser un objeto de transferencia de datos (DTO) y tener el código mínimo.

Podría haber algunos métodos de validación, puede ser algún cálculo básico entre las propiedades y debería serlo.

Answer 2

Este problema es para lo que se usa DCI para resolver, al separar los objetos de datos / POCO simples de la funcionalidad.

Si los datos se actualizan en algún tipo de proceso como lo describe, en DCI modelará ese proceso como un Contexto, basado en un modelo mental de usuario, no en una abstracción como un servicio, fachada o cualquier otro patrón de diseño de ingeniero que desconecte efectivamente el usuario del sistema y difunde la funcionalidad real en todo el sistema.

Sus POCO (lo que es el sistema) deben ser magros, la funcionalidad (lo que hace el sistema) debe contener lo que se necesita para que sus POCO interactúen. Si se esfuerza por mantenerlo tan simple, podrá prescindir de las abstracciones y limitaciones interminables de lo que hoy se llama OO, pero es realmente una orientación de clase, creando tantos problemas en el diseño de software. Incluso el polimorfismo (GOTO moderno) se habrá ido, haciendo que el comportamiento del sistema sea de primera clase.

Answer 3

Su clase se parece más a una especificación de datos, por lo tanto, debe permanecer como tal. Separe el comportamiento del modelo en este caso.

Answer 4

Here encontrarás una respuesta a tu pregunta:

Un POCO no es un DTO. POCO significa Plain Old CLR Object, u Plain Old C # Object. Es básicamente la versión .Net de un POJO, Plain Old Java Object. Un POCO es su objeto de negocio. Tiene datos, validación y cualquier otra lógica de negocio que desee colocar allí. Pero hay una cosa que un POCO no tiene, y eso es lo que lo hace un POCO. Los POCO no tienen métodos de persistencia. Si tiene un POCO de tipo Persona, no puede tener un método Person.GetPersonById () o un método Person.Save (). Los POCO solo contienen datos y lógica de dominio, no hay lógica de persistencia de ningún tipo. El término que escuchará para este concepto es Persistence Ignorance (PI). Los POCO son persistentes e ignorantes.

Prefiero leer el artículo completo, no solo para obtener la respuesta a su pregunta, sino también para entender la diferencia entre el POCO y el DTO .

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; }
}