C # (OOP) вложенные бизнес-объекты

Question

Я получил следующее письмо от коллеги. Мой вопрос это точно. Вложение Business Objects - плохая практика? Кто-нибудь может подсказать это?

Вложенные объекты Когда любая переменная создается в C #, она занимает часть памяти на веб-сервере. Поскольку у нас будет много инструментов, работающих на одном сервере, еще более важно убедиться, что мы не создаем объекты, если не планируем их использовать.

Используя в качестве примера второй объект сотрудника, приведенный выше ... Если нам также нужно было узнать идентификатор руководителя работника (и это было все, что инструмент заполнял и использовал), мы хотели бы убедиться, что класс Employee содержит соответствующую информацию наряду с учетом памяти и процессов в инструменте.

Мы добавили бы строковую переменную 'supervisorId' в класс Employee и добавили соответствующие методы получения и установки.

С другой стороны, мы бы хотели уклониться от вложения другого объекта в объект сотрудника. Такие как: Public Class Employee { приватная строка firstName; приватная строка lastName; приватная строка empId; частный руководитель работника;

    public string FirstName {
        get { return firstName; }
        set { firstName = value; }
    }

    public string LastName {
        get { return lastName; }
        set { lastName = value; }
    }

    public string EmpId {
        get { return empId; }
        set { empId = value; }
    }

 public Employee Supervisor{
     get { return supervisor; }
     set { supervisor = value; }
 }
  }

В этом случае мы не всегда можем использовать значения в экземпляре 'Supervisor' объекта Employee, но переменные создаются в памяти. Это может оказать потенциально катастрофическое влияние на производительность.

В некоторых случаях необходимо вложение объектов: Пример: (Category :: Question) Где каждой категории может быть присвоен список вопросов в массиве.

Answer 1

Краткий ответ на ваш общий вопрос

Разве плохо вкладывать бизнес-объекты?

- это нет.

Длинный ответ таков: похоже, ваша команда страдает от преждевременной оптимизации. Вам необходимо спроектировать свои бизнес-объекты, чтобы они отражали ваш бизнес-домен. Все виды поведения в вашей бизнес-области должны быть проиллюстрированы на вашем бизнес-уровне. После достижения этой цели вы можете проводить тестирование производительности. Фактически измерьте, какие части вашей системы работают слишком медленно, а затем оптимизируйте эти части. Не увлекайтесь предоптимизацией своей бизнес-логики, прежде чем у вас даже появится шанс разобраться в ней.

Разработка и внедрение, затем тест производительности и , а затем оптимизация при обнаружении недопустимой медленности.

Answer 2

Вы можете создать объект, только если у вас есть к нему явный доступ.

public BusinessObject Item
{
    get
    {
        if (_Item == null)
            _Item = new BusinessObject();

        return _Item; 
    }
}
private BusinessObject _Item;  

Answer 3

Я полагаю, что следующий бизнес-объект (объекты передачи данных) вызвал электронную почту:

    /// <summary>
    /// Manufacturer Data Transfer Object
    /// </summary>
    public class MfgBO {
        public int Id { get; set; }
        public string Name { get; set; }
        public bool Active { get; set; }
    }
  }

public class TypeBO {
        public int Id { get; set; }
        public string Name { get; set; }
        public bool Active { get; set; }
    }


 public class ModelBO {
        #region Private Variables

        private int mmtId = -1;
        private int id = -1;
        private string name = String.Empty;
        private bool active = false;
        private MfgBO mfg = new MfgBO();
        private TypeBO type = new TypeBO();

        #endregion
        // Getter and setters below

Глядя на это, ModelBO содержит MfgBO и TypeBO, потому что модель не может быть полной без информации. Он рекомендует использовать ModelBO вместо MfgBO или TypeBO, мы должны иметь переменную int MakeID, строку MakeName, int DeviceTypeId, строку DeviceTypeName и т. Д., В основном перепечатывать поля, которые уже существуют в объектах MfgBO и TypeBO.

Насколько мне известно, ООП имеет больше смысла использовать MfgBO и TypeBO. Какой способ лучше для моих личных знаний? Неужели наличие MfgBO и TypeBO в MakeBO на самом деле будет использовать больше памяти и «потенциально может привести к сбою сервера»?

Answer 4

Из вашего примера кода видно, что вы устанавливаете объект Employee для внешних сотрудников (т. Е. Через установщик свойств), поэтому я думаю, что этот дизайн в порядке. Если бы вы автоматически создавали экземпляр объекта супервизора (скажем, ударив по базе данных) каждый раз, когда создавали «внешний» объект Employee, у вас была бы потенциальная проблема.

Answer 5

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

Если все, что вы будете делать с вложенным объектом, - это получить некоторые его свойства, то вы не должны иметь его и должны хранить свойства напрямую.