Являются ли роли службы и фасад похожими?

Ответ 1

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

Фасад - это способ обернуть что угодно (включая службу), чтобы приятно представить его другому компоненту. Фасады часто используются, когда:

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

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

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

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

Я бы сказал, что DAO - это шаблон дизайна, свой собственный - см. wikipedia.

Если мы противопоставляем DAO с сервисом, мы имеем:

• Уровень API:
  • DAO: мелкозернистый доступ к свойствам
  • Услуга: грубый доступ к услугам
• В случае реализации:
  • DAO: главным образом на клиенте, но сохраняя данные (без поведения) в базе данных
  • Сервис: главным образом на сервере
• Как вызывается интерфейс
  • DAO: клиент напрямую привязывается к объекту в том же пространстве имен и JVM
  • Сервис: клиент - это просто заглушка для работы в сети, кросс-vm или межпространстве имен.

... фасад может отлично получить доступ к нескольким DAO, чтобы выполнить сложную операцию, предоставив простой интерфейс, а служба, похоже, что-то похожее.

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

То же самое происходит с транзакциями, я понимаю, что служба - это место для начала транзакций...

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

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

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

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

Итак, какой стек имеет смысл

контроллер-фасад-dao-контроллер-сервис-dao

или, возможно,

controller-facadade-dao И иногда контроллер-фасад-сервис-dao??

• DAO - это своего рода сервис для базы данных, но на самом деле DAO - это шаблон дизайна.
• Если вы пишете свой собственный DAO, вам никогда не понадобится фасад.

Поэтому правильный ответ:

• контроллер - dao

Ответ 2

Буквально, Фасад, как следует из названия, означает переднюю грань здания. Люди, идущие мимо дороги, могут видеть только фасад, Они ничего не знают о том, что внутри, проводке, трубах и других сложностях. Лицо скрывает все сложности здания и отображает более простое дружеское лицо.

В программных терминах фасад скрывает сложности программных компонентов позади него, предоставляя более простой интерфейс, не имеет собственных функций и не ограничивает доступ к базе. Обычно используется в объектно-ориентированном дизайне. Хорошими примерами являются SLF4J. Это api, который является простым фасадом для систем регистрации, позволяя конечному пользователю подключать нужную систему ведения журнала во время развертывания.

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

Они много похожи, но зависят от того, как вы на это смотрите.

Разница, которую я вижу, Фасады сконструированы наизнанку. Ты выглядишь в подсистеме и дизайн фасада для обеспечения более простого доступа. Сервисы разработаны снаружи. Вы смотрите на своих клиентов/клиентов, которые определяют договориться и разработать сервис.

Ответ 3

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

Я также считаю, что этот шаблон продиктовал структуру ядра J2EE (Session Facade) главным образом потому, что спецификация EJB (по крайней мере, до 2.x) по своей сути привела к созданию плохого уровня сервиса.

Поэтому мой ответ на ваш вопрос будет да - фасад - это фактически сервис, который не был правильно реализован в первый раз. Если вам нужно скрыть сложность кода клиента, это обычно означает, что вам удалось предоставить библиотеку, а не уровень сервиса; поэтому в этом случае Фасад фактически становится вашим уровнем обслуживания.

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

Ответ 4

Обычно эти термины используются только в их конкретных контекстах.

• Общий контекст использования Facade: простой API для сложных частей приложения (например, сторонние библиотеки)

• Контекст служб: разблокировать и обработать бизнес-объекты в системе. (SOA, DAO, Security и т.д.)

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

Например: вызов стороннего API по термину "Сервис" можно считать неправильным использованием из-за неправильного контекста.

Ответ 5

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

Ваш фасад может обернуть некоторые общие интерфейсы, которые могут включать служебные интерфейсы.

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

Ответ 6

Да, фасад и служба не совсем не связаны. И некоторое время мы реализуем Service layer как Facade, чтобы клиент не беспокоился о многих деталях сервиса. Чем проще интерфейс вызова/интерфейса, тем проще и проще код клиента.

Мартин Фаулер говорит... A Service Layer defines an application boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application business logic, controlling transactions and coordinating responses in the implementation of its operations

Таким образом, уровень сервиса используется как Фасад.

Ссылка

Ответ 7

Прежде всего следует отметить, что шаблон проектирования - это описание общей (дизайнерской) проблемы со стандартным решением. В некоторых случаях существует несколько способов решения проблемы таким образом, чтобы она соответствовала всем требованиям (например, модели Iterator и Singleton имеют множество различных реализаций, f.ex. проверяет работу Alexandrescu и сравнивает ее с стандартные решения GoF), и в некоторых случаях существуют разные шаблоны с одинаковым (кодовым) решением (f.ex. сравнить диаграммы классов образцов Composite и Decorator в книге GoF).

В соответствии с GoF целью шаблона Facade является (буквальная цитата):

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

Сервисы имеют целью предоставить пользователю один интерфейс более высокого уровня с заданной функциональностью. Это не обязательно делает его фасадом, потому что сервис строго не по определению a unified interface to a set of interfaces in a subsystem.

Но мы можем сделать лучше, чем

Ваш вопрос был, если шаблоны "похожи". Если мы считаем их "похожими", когда шаблон A равен B, а шаблон B равен A, тогда мы должны ответить на 2 вопроса:

Вопрос 1: - это Service a Facade? Служба должна определенно раскрывать функциональность и определенно является единственным интерфейсом, который предоставляет эту функциональность. Функциональность обычно разлагается на крошечные кусочки, поэтому да, службы соответствуют основным требованиям фасада. Другими словами: столкнувшись с проблемой разоблачения базовых интерфейсов как единого "служебного" интерфейса, шаблон фасада соответствует требованиям и используется для решения проблемы обслуживания. Ответ на этот вопрос: да.

Вопрос 2: - это Facade a Service? Услуги обычно проектируются как многоразовые, несвязанные, слабо связанные единицы функциональности. Мысль о связи между компонентами важна для служб, поскольку они обычно полагаются на интерфейс TCP/IP, такой как SOAP или WCF. Это также означает, что функциональность часто переписывается, чтобы более точно соответствовать парадигме services, которая добавляет неявное требование , обусловленное производительностью для шаблона. У фасадов нет этого дополнительного требования. Другими словами: фасад не является сервисом.

В точном смысле эти понятия тесно связаны, но не то же самое.

Но мы можем сделать лучше

Эта линия мышления ставит вопрос, является ли услуга расширенной версией фасада? Это если сервис отвечает всем требованиям фасада и распространяется на него.

Если вы внимательно прочитаете описание GoF, ответ будет да, то есть: если выполнено одно условие: служба должна выставить подсистемы. На самом деле, я думаю, что это условие обычно имеет место, или вы чрезмерно разрабатываете свои услуги, хотя, строго говоря, я полагаю, что это не является жестким ограничением.

Ответ 8

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

Фасад - при обертке подсистемы (-ов) все еще есть объект, а приложение UI (MVC) обычно живет в одном процессе. Таким образом, связь выполняется обычным способом OO: методы вызова, свойства чтения, прослушивание событий.

Уровень обслуживания - когда уровень бизнес-логики становится зрелым и слишком сложным, чтобы MVC напрямую взаимодействовал с ним, тогда между ними устанавливается уровень обслуживания. Service Layer - это API, который MVC использует как оболочку бизнес-логики. Он не является удаленным и не требуется использовать DTO, поскольку в сообщении не используется провод.

Удаленный фасад - (просто, любая удаленная служба) - это гибрид уровня Facade и Service Layer. Удаленный фасад начинает существовать, когда вы хотите выставить какую-то оболочку над системой (и мы называем ее Фасад) границей распространения. Одной из причин может быть то, что несколько приложений UI (MVC) используют один и тот же удаленный фасад.

-

Сравнения:

Фасад и Уровень обслуживания: они похожи, поскольку оба они обертывают подсистемы. Разница заключается в том, что сервисный уровень больше ориентирован на потребности приложений UI (MVC) и предоставляет функции для упрощения работы с бизнес-логикой. С другой стороны, Facade демонстрирует функциональность, упрощающую бизнес-логику, но не обязательно упрощает связь с приложением UI (MVC).

Фасад и Удаленный фасад (служба?): определенно отличается, поскольку Remote Facade должен использовать DTO как коммуникационные сообщения. Для удаленного фасада потребуется какой-то прокси-сервер, если вы все еще хотите использовать его как обычный объект (свойства, события); но прокси-сервер в любом случае будет использовать DTO для реального объекта, т.е. удаленного фасада.

-

Возможные потоки:

controller-facade-dao - сомнительно, но все же возможно. Фасад обычно не используется для обертывания только DAL. Кроме того, в качестве подсистемы должно быть нечто более зрелое. Но, если фасад является частью бизнес-логики, то да, это возможно. Тем не менее подсистема должна быть более подчеркнута. Для меня DAL-обертка недостаточно, чтобы называть ее Facade.

controller-service-dao - абсолютно возможно. Многие удаленные службы работают напрямую с базой данных через DAL.

controller-facade-service-dao - возможно, если вы рассматриваете сервис как подсистему.

Я бы добавил еще одно, что может иметь смысл:

controller-service [layer]-facade (part of business)-subsystem (e.g. accounting, business on its own)-dao - Я уверен, что вы можете перевести это.

-

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

Ответ 9

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

ОДНАКО, СЕРВИС обеспечивает доступ к ресурсам или набор интерфейсов/объектов и может не обязательно упростить такой доступ. Таким образом, вы можете использовать шаблон фасада для лучшего проектирования своего сервиса, чтобы вы могли сохранить клиента, выясняя, как его использовать.

Ответ 10

Это "контекст" имеет значение. Фасад и служба не противоречат друг другу.

Сначала я никогда не слышал о "Сервисе" и "Фасад" в контексте MVC.

Когда люди говорят об услуге, речь идет скорее о системе или компоненте, обеспечивающих бизнес-значимые действия для внешнего мира. Иногда вы можете увидеть "Сервис", относящийся к "Единице работы" (и, следовательно, транзакции).

Служба также используется в контексте некоторого подхода к распределению приложений: у нас есть Служба поверх DAO, для которой Служба будет получать доступ к данным через DAO, а бизнес-логика помещается в Service layer, что-то вроде этого.

Фасад обычно используется в контексте шаблона проектирования, и основное внимание уделяется "спрятать сложные операции и разоблачить его как простую операцию".

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

Опять же, речь идет о "контексте".

Например, когда вы говорите о расслоении приложения, просто иррационально говорить: "XXX - это фасад доступа к DAO". Точно так же, если вы говорите о "подход к дизайну", разумнее сказать, что "XXX - это фасад для нескольких back-end" вместо того, чтобы называть его "Сервис" здесь (хотя XXX фактически является Сервисом).

Ответ 11

Фасад и Уровень обслуживания имеет свое сходство, но оба они имеют два отличительных значения. Позвольте мне объяснить это, используя простой пример.

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

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

чтобы получить идею высокого уровня, отправьте образец api по следующей ссылке https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing

Вышеуказанный API, расположенный на фасаде ABC, является примером использования Facade.

Он имеет наш сервисный API, а также функции facebook и foursqure check-in на основе выбора клиента. Facebook и API четырех сторон могут иметь конкретные реализации (SOAP, Restful и т.д.) И требования безопасности (OAuth и т.д.) И т.д.

Удовлетворение одного из этих требований API (facebook, foursqure) требует выполнения разных задач. это будут разные подсистемы с нашим требованием проверки.

Таким образом упрощенное упрощение фасада состоит в том, чтобы удовлетворить несколько подсистем, запускаемых одним простым способом.

Но если мы рассмотрим наш собственный API, который является API регистрации, расположенным в MngCheckinSvc. Это API уровня обслуживания. Это API, который содержит наши приложения для проверки требований. Это API обеспечивает открытый доступ из вашего MngCheckinSvc, чтобы обрабатывать требование регистрации для приложения.

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

Этот API (MngCheckinSvc.checkin(....)) может обращаться к другому набору DAO, Internal APIs, может быть другими внутренними службами и т.д., чтобы выполнить регистрацию продавца в приложении.