В веб-проекте мы можем написать слой основных сервисов без знания пользовательского интерфейса?

Question

Я работаю над веб-проектом. Мы используем flex в качестве слоя пользовательского интерфейса. Мой вопрос часто заключается в том, что мы пишем уровень основных сервисов отдельно от уровня web / UI, чтобы мы могли повторно использовать одни и те же сервисы для разных уровней / технологий UI. Таким образом, практически возможно повторное использование одних и тех же сервисов базового уровня без каких-либо изменений / дополнений в API с различными видами технологий / уровней пользовательского интерфейса. Например, тот же базовый уровень обслуживания с технологией пользовательского интерфейса, который поддерживает синхронизированный ответ на запрос (например, jsp и т. д.) и неинхронизированную или управляемую событиями технологию пользовательского интерфейса (например, Ajax, Flex, GWT и т. д.) или с несколькими устройствами, такими как (компьютеры, мобильные телефоны, кпд и т. д.) , Лично я чувствую, что очень сложно написать базовый уровень обслуживания без какого-либо знания пользовательского интерфейса. Ищу мысли от других людей.

Answer 1

Можно конечно. Уровень сервисов чаще всего не содержит состояний, поэтому он просто предлагает методы для вызова с параметрами, поступающими из пользовательского интерфейса. Вы можете представить его как API, который вы вызываете из своих уровней пользовательского интерфейса. Важно , а не , чтобы передать что-либо, связанное с пользовательским интерфейсом, в качестве параметра. Например, не передавайте HttpServletRequest или HttpSession в качестве параметров - получите необходимые значения и передайте их.

Answer 2

Мой вопрос часто пишем основной уровень обслуживания отдельно от слой web / UI, чтобы мы могли использовать то же самое сервисы для разных интерфейсов слой / технологии

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

Например, тот же основной уровень обслуживания с Технология пользовательского интерфейса, которая поддерживает ответ на синхронизированный запрос (например, JSP и т. д.) и не синхронизировать или событие управляемая технология пользовательского интерфейса (например, Ajax, Flex, GWT и т. Д.) Или с несколькими устройствами как (компьютеры, мобильные телефоны, кпк и т. д.).

Бизнес-операция, предоставляемая на уровне обслуживания, теоретически не должна зависеть от того, кто ее называет и какие технологии. Но вы, похоже, сталкиваетесь с общими симптомами:

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

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

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

Я знаю, что иногда трудно полностью отделить бизнес-операцию от ее фактического использования. Давайте рассмотрим разбиение на страницы: если бизнес-операция «Я хочу данные для запроса X», конкретная раскрытая операция также включает в себя некоторое знание пользовательского интерфейса, а именно подкачку страниц.

Я могу только дать общий совет: бороться за четкое разделение между пользовательским интерфейсом и бизнесом, когда дело доходит до данных, форматирования и т. Д., А когда вы не можете, постарайтесь найти самый общий API, который имеет смысл для всех клиентов.

Лично мне очень тяжело написать основной слой службы без каких-либо знание пользовательского интерфейса.

Я согласен, иногда это трудно, но вы, кажется, делаете это правильно - так что продолжайте в том же духе:)

Answer 3

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

Базовым службам просто необходимо знать, какие данные необходимы для выполнения их задач (откуда они не имеют значения).

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