Блог

Плохой ли дизайн иметь некоторые общие функции в объектах POCO в Asp.NET Проект MVC 3 EF CF? Допустим, мне нужна функция для получения кода следующей записи, сгенерированного свойствами сущности :

 public class Warehouse  {
    public string ReceivingRecordCodeFormat { get; set; }
    public int ReceivingRecordCodeNextNumber { get; set; }

    #region functions

    public string GetNextReceivingRecordCode()
    {
        return ...
    }

    #endregion
}
  

Я предлагаю сделать POCOs как можно более простым и создать уровень обслуживания для подобных методов.

Хотя я согласен с maxlego в том, что классы POCO должны быть как можно более простыми, я не уверен, что объектами EF Code First должны быть POCOs.

Моя практика заключается в том, чтобы включать логику, которая влияет только на одну сущность в этом классе сущностей. Особенно, если эти методы могут вызываться из нескольких служб (или нескольких контроллеров, если вы используете их в качестве своего сервисного уровня). В противном случае вашим службам придется обращаться к другим службам, что приводит к тесной связи между службами и проблемам с циклическими ссылками, если вы используете какой-либо контейнер IoC.

Правильная установка логики в объекте имеет наилучший потенциал для повторного использования без необходимости повторять код в нескольких местах.

Для логики, которая включает в себя набор сущностей, я использую сервис, а не пытаюсь сделать это со статическими методами в классе сущностей.

Я также предлагаю использовать модели представления POCO и не передавать ваши объекты EF непосредственно в представления, особенно если вы начнете добавлять к ним логику.