Является ли хорошей практикой добавлять методы в POCOs или создавать отдельный класс для обновления значений POCOs?

Является ли хорошей практикой добавлять методы в POCOs или создавать отдельный класс для обновления значений POCOs в случае необходимости?

Например,

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

Я использую его только для хранения данных для обновления model entity или для возврата данных в представление. Иногда мне нужно обновить некоторые свойства до того, как я отправлю object в представление, например, список с именем Roles в приведенном выше примере, поэтому мне интересно, добавить ли я методы в класс POCO или это лучше создать класс для обновления свойств?

Ответ 1

Здесь вы найдете ответ на свой вопрос:

A POCO не является DTO. POCO означает объект Plain Old CLR или обычный Старый объект С#. В основном это версия .Net POJO, Plain Old Объект Java. POCO - это ваш бизнес-объект. Он имеет данные, валидации и любой другой бизнес-логики, которую вы хотите там. Но это одно, чего нет у POCO, и вот что делает его POCO. У POCOs нет методов настойчивости. Если у вас есть POCO типа Person, вы не можете использовать метод Person.GetPersonById() или метод Person.Save(). POCOs содержат только логику данных и домена, никакой логики настойчивости любого рода. Термин, который вы услышите для этого Концепция - Непрерывность (PI). POCOs - это Persistence Невежественные.

Я предпочитаю читать всю статью, а не просто получить ответ на ваш вопрос, но также понять разницу между POCO и DTO.

Ответ 2

В этом случае POCO имеет роль ViewModel, и, таким образом, IMHO, он должен быть просто объектом передачи данных (DTO) и иметь только минимальный код.

Могут быть некоторые методы проверки, может быть некоторый базовый расчет среди свойств и должен быть им.

Ответ 3

Ваш класс больше похож на спецификацию данных, поэтому должен оставаться таковым. Отделите поведение от модели в этом случае.

Ответ 4

Эта проблема заключается в том, что DCI используется для решения, отделяя простые объекты POCO/данных от функциональности.

Если данные будут обновляться в каком-то процессе, как вы описываете, в DCI вы моделируете этот процесс как контекст, основанный на пользовательской ментальной модели, а не на некоторой абстракции, такой как сервис, фасад или любой другой шаблон проектирования для проектирования, который эффективно отключает пользователя от системы и распространяет фактические функции в системе.

Ваши POCO (то, что система) должно быть худым, функциональность (что делает система) должна содержать то, что необходимо для взаимодействия ваших POCO. Если вы попытаетесь сохранить это настолько просто, вы сможете обойтись без бесконечных абстракций и ограничений того, что сегодня называется OO, но действительно ориентировано на класс, создавая так много проблем в разработке программного обеспечения. Даже полиморфизм (современный GOTO) исчезнет, сделав поведение системы первоклассным.

Ответ 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; }
}