Использование отдельного класса для подключения к сервису при использовании MVP для формы

Question

Рассмотрим случай формы, которая получает свои данные от службы и реализуется с использованием шаблона MVP.Нужно ли изолировать доступ к сервису в отдельном классе или его можно сохранить в самом классе Model.В моем конкретном случае класс модели действует только как проход к классу доступа к данным, который в конечном итоге вызывает сервис.Класс доступа к данным имеет логику, которая используется для обратных вызовов службы и запроса службы в определенные промежутки времени для любых обновлений.

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

Answer 1

Простая структура кода (имеется в виду небольшое количество классов) не обязательно означает простое обслуживание ( см. Недавний пост Айенде об этом ). Я предлагаю придерживаться принципа единой ответственности (ПСП). Обязанность модели в MVP заключается в том, чтобы инкапсулировать данные в представление, , но , в вашем случае она получает другую ответственность: получение данных из службы. Помимо этой перегрузки обязанностей, я вижу две другие проблемы с этим:

1. Что произойдет, если вызов службы не удастся? Тогда вы будете вынуждены обработать это в коде представления.
2. Какие обязанности выполняет ведущий в вашем случае?

Мне кажется, ваша архитектура на самом деле не MVP (но, не видя код, я могу ошибаться).

Кроме того, фактическая реализация шаблона MVP зависит от технологии GUI, которую вы используете. Мои общие предложения:

• Придерживайтесь Пассивного вида .
• Держите модель тупой. Я обычно использую простые классы POCO / POJO, никаких обратных вызовов. Я использую C # просмотра событий в WinForms, чтобы уведомить докладчика о любых событиях пользовательского интерфейса.
• Сделайте модель удобной для просмотра: модели, как правило, должны быть реализованы для нужд представления, чтобы код представления был минимальным.
• Ведущий - король. Храните всю бизнес-логику внутри докладчиков (и других служб / репозиториев).

ОБНОВЛЕНИЕ: ответ на ваш комментарий:

• Да, вы должны хранить данные в вашей модели.

• Если я правильно понимаю, вы выставляете события / обратные вызовы в модели для обработки исключений. Затем вы позволяете представлению извлекать данные, и в случае сбоя вызова службы докладчик обрабатывает это (снова), вызывая представление, чтобы дать пользователю знать, что сбой службы. Я вижу несколько проблем с этим подходом:

  1. Он может создавать запутанные пути выполнения, когда возникает исключение службы: Presenter -> View -> Model -> Presenter -> View. Это может быть сложно для отладки и модульного тестирования.
  2. Откуда вы знаете , где представление было (с точки зрения заполнения представления данными модели), когда произошло исключение?

Мой обычный подход заключается в том, что докладчик выполняет всю выборку и обработку исключений за до , когда представление получает в свои руки данные модели. Таким образом, мне не нужны никакие обратные вызовы в модели, поскольку я могу обрабатывать исключения с помощью простых блоков try-catch в презентере. Модель становится просто держателем статических данных, а не шлюзом для внутренних сервисов.

Answer 2

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

public class SomePresenter
{
    private readonly ISomeView _view;
    private readonly ISomeRepository _repository;

    public class SomePresenter(ISomeView view, ISomeRepository repository)
    {
        _view = view;
        _repository = repository;
    }

    public void Foo()
    {
        var model = _repository.GetModel();
        // TODO: work with the model and update the view
    }
}

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

Answer 3

Такой класс обычно называется Service Agent.Сервисный агент используется для слабой связи между сервисом и клиентом и для поддержки некоторой промежуточной логики.На основании вашего описания ваш класс доступа к данным уже является агентом службы.