Ввод логики в getMers ViewModel

Question

Что вы думаете о включении Get-logic в геттеры ViewModel? Что-то вроде:

public class DummyViewModel
{
    public int Id { get; set; }

    private DummyObject myObject;

    public DummyObject MyObject
    {
        get
        {
            if (MyObject == null)
            {
                DummyRepository repo = new DummyRepository();
                myObject = repo.Get(Id);
            }
            return myObject;
        }
    }

}

Это плохая практика или совершенно нормально? Я обнаружил, что мои контроллеры действительно раздуты, выполняя всю логику get, но я действительно не могу понять, куда мне их поместить ...

Моя причина сделать это таким образом, это то, что я могу передать ViewModel различным типам представления, и только необходимый просмотр БД будет выполнен на основе того, какое свойство запрашивается.

Answer 1

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

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

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

Answer 2

Лично я не включаю никакой логики в мои модели представлений - они довольно глупые DTO. Я, конечно, не стал бы возлагать на ВМ ответственность за ее собственную загрузку через репозиторий.

Answer 3

Ваш вопрос общий, но я отвечу как можно лучше.

Мне не нравятся эти вещи:

1) Тестируемость. Ваша собственность создает хранилище, как вы собираетесь смоделировать хранилище и проверить это?

2) Ленивая загрузка. Ленивая загрузка является потенциальным ударом по производительности, и модель представления не должна этого делать. Что произойдет, если вы привяжете свою модель представления к сетке с сотнями записей?

3) Exposing Id. Ваше свойство Id (которое, как я предполагаю, является значением первичного ключа объекта) имеет установщик. Собираетесь ли вы представить этот идентификатор в виде? Если нет, избавьтесь от него, если так, удалите сеттер. Установщик подразумевает, что представление должно выполнять некоторую функциональность biz для поиска правильного значения, и это нарушает SoC.