Контроллер <-> Взаимодействие с сервисным компонентом - PullRequest
5 голосов
/ 13 января 2010

ОБНОВЛЕНО:

У меня есть настольное приложение, взаимодействующее со следующими компонентами:

  • Интерфейс Winforms.
  • Сервис (в-процесс C # класса, который содержит бизнес-логику для do вещи.
  • Контроллер (класс C #, который координирует события, вызванные пользовательским интерфейсом и вызывает методы обслуживания).

Если контроллер просит службу что-то сделать, но эта служба сначала требует от контроллера чего-то большего (т. Е. Данные, которые контроллер должен использовать для получения пользовательского интерфейса), как служба должна заставить контроллерсделать это?


Я доволен тем, что

  • Пользователь общается с
  • Пользовательский интерфейс, который общается с
  • Контроллер, который взаимодействует с
  • Сервисным компонентом (не путать с веб-сервисом или сервисом вне процесса), который взаимодействует с
  • Data / Repositories, которые ...

и т. Д.

Однако, что касается Контроллера, связывающегося с Сервисом, какой метод лучше для этого?Должны ли:

  1. Методы обслуживания быть достаточно детализированными и генерировать исключения, если что-то не так, поэтому контроллер знает, двигаться ли дальше или сказать пользователю, что что-то пошло не так?Или ...
  2. Сервисные методы возвращают объекты, которые контроллер может проверить, чтобы решить, что делать дальше?

Мне нравится первый вариант, потому что второй может означать взрыв класса,где вам нужен класс ServiceResult в стиле для каждого метода Service.

Я спрашиваю, потому что, конечно, компонент Service не может сказать UI, что делать, может только контроллер, но контроллер не знает, чтосообщить интерфейсу без получения обратной связи от Сервиса.

Что вы думаете?

Ответы [ 5 ]

2 голосов
/ 22 января 2010

Лучшим вариантом, вероятно, является использование модели события или делегата - например, контроллер подписывается на событие «нужна дополнительная информация» и отображает соответствующую форму. Возврат дополнительных данных в сервис может быть осуществлен несколькими различными способами, но он будет в значительной степени зависеть от особенностей вашего проекта (например, ваши сервисы не сохраняют состояния и т. Д.)

Вы написали юнит-тесты для своего сервиса? Если нет, то этот процесс, вероятно, поможет вам уточнить, что вы хотите от вашего дизайна.

2 голосов
/ 13 января 2010

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

Здесь есть несколько вопросов:

  1. Как контроллер находит сервис?
    Если вы хотите иметь многократно используемые, расширяемые и ... сервисные объекты, зависимость между вашим контроллером и сервисными классами должна быть слабо связана. Избегайте любых методов жесткого соединения. Вместо этого попробуйте внедрить класс обслуживания в ваш контроллер (используя контейнер IOC), а также вы можете использовать Шаблон проектирования локатора службы .

  2. Как связаться с сервисом?
    Ну, это зависит от размера вашего приложения. Вы можете использовать корпоративные сервисные технологии, такие как веб-сервисы, просто использовать сервисы приложений. На основании этого вы определяете протокол между контроллером и службой.

  3. Какие данные служба должна вернуть контроллеру?
    Помните, что сервисный уровень не должен ничего знать о пользовательском интерфейсе Ответственность за решение о том, куда и что делать, лежит на контроллере в зависимости от ответа сервисного объекта. Зачем? Представьте, что этот класс обслуживания необходимо использовать для другого пользовательского интерфейса (скажем, из веб-приложения для flex, silverlight или настольного приложения). Если вы добавите навигационную логику (в качестве крайнего примера, логику / форматирование пользовательского интерфейса) в класс обслуживания, она не будет использоваться повторно для другой системы пользовательского интерфейса, а также не будет использоваться повторно даже для других классов обслуживания и контроллеров в одном приложении .

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

0 голосов
/ 23 января 2010

Рассматривали ли вы использование Model View Presenter ?

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

0 голосов
/ 22 января 2010

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

Когда служба не получает достаточно данных, это из-за того, что пользователь вводит неверные данные? Если это так, то контроллер должен выполнить проверку входных данных и отобразить соответствующее сообщение или сообщение об ошибке.

Если ожидается, что пользователь не предоставит все данные сразу, тогда контроллер должен знать, что служба не примет данные как есть. Следовательно, контроллер должен управлять беседой с пользователем через пользовательский интерфейс, а затем в конце концов передать все службе.

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

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

0 голосов
/ 13 января 2010

Смотри мой вопрос здесь

Есть некоторые недостающие детали, чтобы лучше ответить на ваш вопрос:

Это веб-сценарий или сценарий рабочего стола?

Если рабочий стол - это отключенный сценарий? (например, богатый клиент с удаленными сервисами) или клиент и сервис на одной машине?

Если веб - это классическое веб-приложение 1.0? (представление создается как страница) или расширенный клиент? (AJAX, Flex, SilverLight) где контроллер иногда может быть в клиенте? (Flex)

Все это может существенно повлиять на решения.

Кстати, вы пропустили модель по назначению?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...