Должны ли службы действовать как контроллеры? - PullRequest
Новая
       51

Должны ли службы действовать как контроллеры?

1 голос
/ 25 мая 2011

Я довольно много занимался (веб) разработкой в ​​обычном мышлении MVC, и я думаю, это мне хорошо помогло.

Однако теперь я должен разделить свое приложение так, чтобы моиfront-end должен получить доступ к серверным функциям как services .

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

Это хороший способ сделать это?

Спасибо

PS: Рассматриваемая технология на стороне сервера - это PHP, а на стороне клиента - Adobe Flex (ActionScript).

Ответы [ 2 ]

4 голосов
/ 25 мая 2011

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

Подход, который вы, похоже, предлагаете, заключается в создании фасада , который стоит между моделью (AKA PHP Code, который выполняет «тяжелый бэкэнд-лифт») и видом (AKA Flex Front).конец).У меня нет наследственной проблемы с этим;особенно если у вас уже реализован бэкэнд, содержащий всю тяжелую бизнес-логику.Я бы считал этот фасадный слой служебным слоем и считал бы его частью модели;не является частью контроллера.

При попытке создать архитектуру Model-View-Controller-Services (MVCS) между Flex и некоторым бэкэндом;Обычно я делаю это так:

Представления реализованы в виде компонентов Flex.

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

Уровень обслуживания реализован на сервере;PHP в вашем случае.Может случиться так, что у вас есть параллельный класс обслуживания во Flex для каждого из ваших сервисов на стороне сервера.

На уровне модели есть классы для выполнения соответствующей бизнес-логики;проверять данные, сохранять их в базе данных, извлекать их из базы данных и использовать любую другую бизнес-логику, которая вам нужна.Часто в рамках модели у меня есть классы Value Object.Классы Value Object часто параллельны в ActionScript и используются для передачи данных между службой на стороне сервера и контроллером на стороне клиента.

Итак, это работает примерно так:

  1. Пользователь взаимодействует с представлением
  2. Представление отправляет событие на контроллер
  3. Контроллер выполняет удаленный вызов службы на сервере
  4. Служба вызывает модель дляполучить данные
  5. Модель получает запрос, выполняет соответствующие действия, создает объект значения - или массив объектов значения - и возвращает его службе
  6. Служба возвращает результаты вконтроллер на стороне клиента
  7. Контроллер делает что-то для обновления представлений

Существует множество платформ, помогающих этому процессу, особенно для «инкапсулированной» связи между уровнями приложения.,

Во многих случаях;грань между «что должно идти в модели / что должно идти в представлении» размыта.Когда мы разрабатываем приложения Flex (или AJAX, Silverlight или любой интеллектуальный клиент), часто нам нужны интеллектуальные представления;поэтому некоторая бизнес-логика может быть реализована как часть представления.Все в порядке;мы должны сбалансировать функциональность приложения с «идеальным» случаем абстракции.

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

1 голос
/ 25 мая 2011

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

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

Класс PostService содержит экземпляр RemoteObject и является просто заглушкой на стороне клиента для вашей удаленной (php) службы.Он возвратит ResultEvent или FaultEvent в функции onResult или onFault.

Теперь вы можете создать класс декоратора, который реализует тот же интерфейс.Я назвал его PostServiceDecorator, но вам лучше дать ему имя, которое даст вам представление о том, какая именно обработка выполняется.Этот класс, в свою очередь, содержит экземпляр вашего PostService.PostService передаст ResultEvent в функцию, переданную в качестве аргумента PostServiceDecorator, и последний теперь может обработать это событие и передать, скажем, ArrayCollection объектов post в функцию onResult, которую она была передана.

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

Есть одно предупреждение, о котором я знаю: это не шаблон декораторав правильном смысле, поскольку вы не можете просто заменить один PostServiceDecorator на PostService в коде, который его использует.Они передают различные объекты обратным вызовам, поэтому ваш код будет прерываться, если вы замените их.Интерфейс просто заставляет вас реализовать все методы в обоих классах.

...