Плохо ли если класс самодостаточен, в плане получения каких то данных необходимых для его полноценной работы?

Question

[jammywork1]

Не могу решить как правильнее будет действовать в такой ситуации.
примерчик:

public class Model
    {
        public Model(int id, string path)
        {
            ID = id;
            Path = path;
        }

        public int ID { 
            get; 
            protected set; 
        }

        public string Path { 
            get; 
            protected set; 
        }
    }

    public class UpgradeModelA : Model
    {
        public UpgradeModelA(int id, string path) 
            : base(id, path)
        {
            
        }
        public void Method1() { }

    }

    /// <summary>
    /// Вариант 1: child элементы я получаю из репозитория вне класса, после чего вызываю конструктор передавая туда параметры
    /// </summary>
    public class UpgradeModelB : Model
    {

        public UpgradeModelB(int id, string path, IEnumerable<UpgradeModelA> children)
            : base(id, path)
        {
            Children = children;
        }

        public void Method2() { }
        public IEnumerable<UpgradeModelA> Children { 
            get; 
            protected set; 
        }
    }


    /// <summary>
    /// Вариант 2: child элементы я получаю из репозитория внутри класса, внутри конструктора
    /// </summary>
    public class UpgradeModelB : Model
    {

        public UpgradeModelB(int id, string path)
            : base(id, path)
        {
            Children = Repository.getItemsByParentID(id);
        }

        public void Method2() { }
        public IEnumerable<UpgradeModelA> Children
        {
            get;
            protected set;
        }
    }

Тоесть хорошо ли или плохо всё же когда классы самодостаточны, и наполняются данными к примеру сами пользуюясь репозиториями, либо же стоит жёстко розграничивать получение/обновление данных в классе.

Answer 1

[Станислав Макаров]

Зависит от того, какую ответственность вы "отдаете" в класс. Если это так называемый "value object", т.е. некий неизменяемый композит, то лучше ему в конструктор передать сразу готовые значения. Если же это самостоятельный объект с внятным жизненным циклом и определенной ответственностью - тогда конечно логично чтобы он сам брал данные из репозитория.
Вам нужно почитать про Dependency Injection - это как раз та "середина" между двумя альтернативами, что вы предложили в виде фрагментов кода. Обращаться к глобальном объекту репозитория - это также антипаттерн. Гораздо лучший вариант - это когда объекту при создании передается (!) репозиторий в конструкторе, а объект уже САМ делает выборки необходимых данных. Это как раз и есть удачный вариант спуска от общего к частному. Плюс, вся логика сосредоточена в классе - я всегда могу добавить новую Модель (если следовать вашим примерам), которая также берет репозиторий, но вытаскивает из него уже ДРУГИЕ сведения.
Вот стандартный туториал, в котором роль вашего "класса" выполняет ASP.NET-контроллер, и он получает репозиторий в конструкторе: www.asp.net/web-api/overview/advanced/dependency-i...

Вообще принцип всегда такой - если есть некоторая переменная или значение, то есть N точек, из которых можно получить к ней доступ. Чем меньше этих точек - и при этом вы можете без извращений реализовать нужную вам бизнес-логику - тем лучше. И чем ближе в коде эти точки расположены друг к другу - тем лучше. Всегда удобнее работать с кодом, когда данные конкретной сущности и логика их обработки умещаются хотя бы в одном файле.

Comments

[jammywork1]

Про DI читал, как в общем и про другие паттерны. Но сделать выводов о том как действовать лучше не могу, всё время двоякое чувство что я опять на говнокодил. Из за этого топчусь много на месте, бывает переписываю одно и тоже по нескольку раз. Репозиторий вообще до этого получал из IoC контейнера, потом убрал... Спасибо за помощь.

[Станислав Макаров]

jammywork1
> Но сделать выводов о том как действовать лучше не могу
значит до конца не понимаете и не можете свои действия
> переписываю одно и тоже по нескольку раз
это нормально в случае, если вы увидели ситуацию более полно, чем при первой попытке. Если вы переписали и совершенно не понимете, как лучше - до или после - тогда см. выше
> Репозиторий вообще до этого получал из IoC контейнера, потом убрал...
о, даже так.. А почему? Что на ваш взгляд было неправильным/нелогичным?

[jammywork1]

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

Answer 2

[Pavel K]

По-моему если работа с данными идёт внутри класса, то и сами данные стоит получать внутри.
Иначе какой смысл, если вам снаружи дадут данные а вы не сможете с ними работать?

Comments

[jammywork1]

Да забыл и такой вариант был, в конструкторе к примеру передовался ID, на основе которого же и поиск данных и последующая инициализация, либо Exception... Ну вообще довод довольно справедливый, спасибо Вам.

[Pavel K]

jammywork1: пожалуйста. Вообще если мучаетесь с выбором и Вы перфекционист - не переживайте, это нормально =) да и не забывайте - никогда не поздно переделать.

Answer 3

[MrDywar Pichugin]

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

Comments

[jammywork1]

Спасибо!