ti-enxame.com

Os papéis de um serviço e uma fachada são semelhantes?

Quanto mais leio, mais confuso fico.

Observe que toda a pergunta está relacionada a como o serviço e as fachadas se encaixam no padrão MVC.

Meu entendimento é que uma Fachada não é um objeto super-inteligente, é simplesmente uma maneira de expor uma interface/API simples para executar uma operação complexa (por exemplo: executar um pagamento de 10 $, é uma operação complexa que envolve vários operações, mas essa complexidade pode ser tratada por uma fachada que chamará apenas o objeto correspondente em uma ordem específica ... etc ...)

Agora, um serviço é uma maneira de executar chamadas para vários DAOs para obter estruturas de dados complexas (não tenho muita certeza disso, mas é o que entendi até agora).

A questão então é: qual é a diferença entre uma fachada e um serviço? No final do dia, a fachada pode acessar perfeitamente vários DAOs para executar uma operação complexa, fornecendo uma interface simples, e um serviço parece algo semelhante.

O mesmo acontece com as transações, entendo que um serviço é o local para iniciar as transações, mas também sinto que elas também poderiam ser colocadas em fachadas, afinal, uma fachada também pode chamar vários DAOs.

Então, qual pilha faria mais sentido

controlador-fachada-dao controlador-serviço-dao

ou talvez

controller-facadade-dao E algumas vezes controller-facade-service-dao ??

47
Juan Antonio Gomez Moriano

Um serviço é uma maneira de gravar uma interface em um sistema externo, como um armazenamento de identidade LDAP, um gateway de pagamento ou uma interface de gerenciamento de aplicativos. É uma maneira conceitual de ver o sistema externo como um provedor de serviços úteis, talvez com comportamentos internos, em vez de um conjunto passivo a ser operado.

Uma fachada é uma maneira de agrupar qualquer coisa (incluindo um serviço) para apresentá-la bem a outro componente. As fachadas são frequentemente usadas quando:

  • Uma biblioteca ou componente é complexo e seu aplicativo precisa apenas de um subconjunto dele. Sua fachada apresenta a API simplificada para o aplicativo
  • Você está usando várias bibliotecas ou componentes e precisa unificá-los, apresentando uma API consolidada ao aplicativo
  • A biblioteca que você está usando possui uma configuração complexa ou um conjunto de dependências, e a fachada agrupa tudo isso no contexto do seu aplicativo.

O que é realmente confuso é que você pode (e costuma fazer) criar uma fachada para um ou mais serviços. O serviço é a maneira pela qual o componente realmente acessa o recurso, e a fachada é o bit que simplifica o componente (como configuração de opções, conexão, etc).

Se você escrever seu próprio DAO, provavelmente criará seu serviço exatamente como precisa, portanto, escrever uma fachada é uma indicação de que você fez errado. Se o DAO for construído por terceiros e for mais complexo que suas necessidades, , então , você poderá fazer a fachada do serviço.

Agora, um serviço é uma maneira de realizar chamadas para vários DAOs para obter estruturas de dados complexas (não tenho muita certeza disso, mas é o que entendi até agora).

Eu diria que o DAO é um padrão de design próprio - consulte a Wikipedia .

Se compararmos um DAO com um serviço, temos:

  • Nível da API:
    • DAO: acesso refinado a propriedades
    • Serviço: acesso de granulação grossa aos serviços
  • Onde está a implementação:
    • DAO: Principalmente no cliente, mas armazenando dados (sem comportamento) no banco de dados
    • Serviço: Principalmente no servidor
  • Como a interface é chamada
    • DAO: O cliente se liga diretamente ao objeto no mesmo namespace e JVM
    • Serviço: o cliente é simplesmente um stub para uma operação de rede, cross-vm ou cross-namespace

... a fachada pode acessar perfeitamente vários DAOs para executar uma operação complexa, fornecendo uma interface simples, e um serviço parece algo semelhante.

Uma fachada poderia encerrar a camada DAO, mas eu realmente não vejo isso acontecendo de uma maneira útil. Provavelmente, você precisa de uma API para acessar as propriedades individuais dos objetos, percorrer o gráfico de objetos e similares, e é exatamente isso que o DAO fornece.

O mesmo acontece com as transações, entendo que um serviço é o local para iniciar transações ...

Absolutamente, porque a transação é um serviço fornecido pelo banco de dados e em outro componente ou sistema

... mas também sinto que eles também poderiam ser colocados em fachadas, afinal, uma fachada também pode chamar vários DAOs.

E, de várias maneiras, o serviço do gerenciador de transações é uma fachada para uma implementação de back-end muito mais complexa, coordenando a transação na Web, aplicativo, banco de dados e outros componentes com reconhecimento de transação. No entanto isso já é abstraído pela implementação do serviço de transação. No que diz respeito a nós, o usuário, existe apenas a interface pública.

Este é, de fato, o ponto conceitual desses padrões de design - fornecer a quantidade certa de API ao usuário, abstraindo as complexidades da implementação por trás da parede de ferro da interface do componente.

Então, qual pilha faria mais sentido

controlador-fachada-dao controlador-serviço-dao

ou talvez

controller-facadade-dao E algumas vezes controller-facade-service-dao ??

  1. O DAO é um tipo de serviço para o banco de dados, mas realmente o DAO é um padrão de design em si.
  2. Se você escrever seu próprio DAO, nunca precisará de uma fachada.

Portanto, a resposta correta é:

  • controlador - dao
43
Andrew Alcock

Literalmente, Fachada como o nome sugere, significa a face frontal do edifício. As pessoas que passam pela estrada só podem ver a fachada. Elas não sabem nada sobre o que há dentro dela, a fiação, os canos e outras complexidades. O rosto esconde todas as complexidades do edifício e exibe um rosto amigável mais simples.

Em termos de software, a fachada oculta as complexidades dos componentes de software por trás, fornecendo uma interface mais simples, não possui funcionalidade própria e não restringe o acesso ao subsistema . Comumente usado em Design Orientado a Objetos. Bons exemplos são o SLF4J - é uma API que é uma fachada simples para sistemas de registro, permitindo que o usuário final conecte o sistema de registro desejado no momento da implantação.

Um serviço é uma interface pública que fornece acesso a uma unidade de funcionalidade e sempre é gravada em uma especificação. Ele precisa oferecer suporte aos contratos de comunicação ( comunicação, formatos, protocolos, segurança, exceções etc. , que seus diferentes consumidores exigem. Há serviços de processo - encapsulamento de fluxos de trabalho de negócios, serviço de lógica de negócios - encapsulamento de regras/funções, serviços de dados - interação com entidades, acesso a dados gerência, serviços de infraestrutura - funções de utilidade, como monitoramento, registro e segurança. Os serviços são principalmente unidades de funcionalidade reutilizáveis, não-associadas e pouco acopladas.

Eles são muito semelhantes, mas depende de como você olha para ele.

A diferença que vejo, Fachadas são projetadas de dentro para fora. Você analisa o subsistema e cria uma fachada para fornecer acesso mais simples. Os serviços são projetados de fora para dentro. Você observa seus clientes definir um contrato e projetar o serviço.

16
Manish Singh

FACADE é um padrão de design que resolve o problema em que é necessária uma interface unificada para muitas interfaces em um subsistema, para que ele defina uma interface de nível superior que facilite o uso do subsistema.

NO ENTANTO, UM SERVIÇO fornece acesso a recursos ou a um conjunto de interfaces/objetos e pode não necessariamente simplificar esse acesso. Assim, você pode empregar o padrão de fachada para projetar melhor seu serviço, para que você possa salvar o cliente descobrindo como construir para usá-lo.

2
Samuel

Meu entendimento do padrão clássico do GoF Facade é que ele visa principalmente ocultar um design pobre. Como regra geral, eu diria que é necessário apenas uma Fachada para código legado.

Eu também acho que esse padrão se tornou o padrão principal do J2EE (Session Facade) principalmente porque a especificação EJB (pelo menos até 2.x) inerentemente resultou em um projeto inadequado da camada de serviço.

Portanto, minha resposta para sua pergunta seria sim - uma fachada é na verdade um serviço que não foi implementado corretamente na primeira vez. Se você precisar ocultar a complexidade do código do cliente, normalmente significa que você conseguiu fornecer apenas uma biblioteca, não uma camada de serviço; portanto, nesse caso, o Facade se torna sua camada de serviço.

Por outro lado (supondo que você tenha uma camada de domínio decente), se você realmente precisar fornecer a opção de gerar fluxos complexos com uma única chamada de método (algo parecido com macros/aliases), isso geralmente seria melhor colocado na camada de aplicação e não em seu domínio principal - observe que eu mudei a terminologia de camadas para o design orientado a domínio, onde não há camada de "acesso a dados" ou "serviço", mas "aplicativo", "domínio", "infraestrutura".

2
Costi Ciudatu

Antes de tentar responder, deixe-me esclarecer uma coisa: existem três coisas distintas nos aplicativos corporativos - Fachada, Camada de serviço e Fachada remota.

Fachada - ao agrupar o (s) subsistema (s), ainda é um objeto e o aplicativo de UI (MVC) geralmente vive no mesmo processo. Assim, a comunicação é feita da maneira usual OO: chamando métodos, lendo propriedades, ouvindo os eventos.

Camada de Serviço - quando a camada de lógica de negócios se torna madura e complexa demais para o MVC interagir diretamente com ela, a Camada de Serviço é colocada entre elas. Camada de serviço é uma API que o MVC usa como invólucro da lógica de negócios. Não é remoto e não é necessário usar o DTO, pois não há fio envolvido na comunicação.

Fachada Remotasimplesmente, qualquer serviço remoto) este é um híbrido da Fachada e da Camada de Serviço. O Remote Facade começa a existir quando você deseja expor algum tipo de invólucro sobre o sistema (e nós o chamamos de Fachada) como um limite de distribuição. Um dos motivos pode ser o de permitir que vários aplicativos de UI (MVC) usem a mesma Fachada Remota.

-

--- (Comparações:

Fachada vs. Camada de serviço: são semelhantes, pois ambos envolvem subsistemas. A diferença é que a Camada de Serviço é mais orientada para as necessidades do aplicativo de UI (MVC) e expõe funções para simplificar o trabalho com a lógica de negócios. Por outro lado, o Facade está expondo a funcionalidade para simplificar a lógica de negócios, mas não simplifica necessariamente a comunicação com o aplicativo UI (MVC).

Fachada vs. Fachada remota (serviço?): definitivamente diferente, pois a Fachada remota deve usar DTOs como mensagens de comunicação. O Remote Facade precisará de algum tipo de proxy se você ainda quiser usá-lo como um objeto regular (propriedades, eventos); mas o proxy usará os DTOs para o objeto real, ou seja, Fachada remota.

-

Possíveis fluxos:

controller-facade-dao - duvidoso, mas ainda possível. Fachada geralmente não é usada para envolver apenas DAL. Além disso, deve haver algo mais maduro como subsistema. Mas, se a fachada fizer parte da lógica de negócios, sim, isso é possível. Ainda assim, o subsistema deve ser mais enfatizado. Para mim, o invólucro do DAL não é suficiente para chamá-lo de Fachada.

controller-service-dao - absolutamente possível. Muitos serviços remotos trabalham diretamente com o banco de dados através do DAL.

controller-facade-service-dao - talvez, se você tratar o serviço como um subsistema.

Eu acrescentaria mais um que pode fazer sentido:

controller-service [layer]-facade (part of business)-subsystem (e.g. accounting, business on its own)-dao - Tenho certeza que você pode traduzir isso.

-

Lembre-se, o serviço (ou fachada remota) pode existir em qualquer lugar do fluxo. Isso é apenas ditado pelas suas necessidades de distribuição.

1
Tengiz

Sim, Fachada e Serviço não são totalmente independentes. E algum tempo implementamos a camada de serviço como fachada, para que o cliente não se preocupe com muitos detalhes do serviço. Quanto mais simples a chamada/interface de um serviço é o código de clientes mais simples e fácil.

O Martin Fowler diz ...

Uma Camada de Serviço define o limite de um aplicativo [Cockburn PloP] e seu conjunto de operações disponíveis da perspectiva da interface das camadas do cliente. Ele encapsula a lógica de negócios do aplicativo, controlando transações e coordenando respostas na implementação de suas operações

Portanto, a camada de serviços é usada às vezes como Fachada.

Ref

1
rai.skumar

Geralmente esses termos são usados ​​apenas em seus contextos específicos.

  • Contexto de uso comum do 'Facade': API simples para partes complexas do aplicativo (como bibliotecas de terceiros)

  • Contexto de 'serviços': desbloqueie e aplique à superfície as entidades comerciais no sistema. (SOA, DAO, segurança etc.)

Você pode ver os padrões como uma linguagem que evolui. Nunca pareceu ser um final perfeito. Cada padrão tem sua própria história e contexto. Às vezes, as classes podem ser vistas como serviços e fachadas ao mesmo tempo, às vezes não.

Por exemplo: chamar a API de terceiros pelo termo 'Serviço' pode ser considerado uso indevido, devido ao contexto errado.

1
IlliakaillI

A primeira coisa a observar é que um padrão de design é uma descrição para um problema comum (de design) com uma solução padrão. Em alguns casos, existem várias maneiras de resolver o problema de uma maneira que atenda a todos os requisitos (por exemplo, os padrões Iterator e Singleton têm várias implementações diferentes; por exemplo, verifique o trabalho de Alexandrescu e compare com as soluções padrão do GoF) e, em alguns casos, existem padrões diferentes com a mesma solução (código) (por exemplo, compare os diagramas de classes dos padrões Composto e Decorador no livro do GoF).

De acordo com o GoF, o objetivo do padrão Facade é (aspas literais):

Forneça uma interface unificada para um conjunto de interfaces em um subsistema. Fachada define uma interface de nível superior que facilita o uso do subsistema.

Os serviços têm a intenção de fornecer ao usuário uma única interface de nível superior com uma determinada funcionalidade. Isso não necessariamente a torna uma fachada, porque um serviço não é estritamente falando, por definição, um unified interface to a set of interfaces in a subsystem.

Mas podemos fazer melhor que isso

Sua pergunta foi se os padrões são "semelhantes". Se considerarmos que eles são "semelhantes" quando o padrão A é igual a B e o padrão B é igual a A, então devemos responder 2 perguntas:

Pergunta 1: é um Service a Facade? Um serviço definitivamente deve expor a funcionalidade e é definitivamente uma única interface que expõe essa funcionalidade. A funcionalidade é normalmente decomposta em pequenos pedaços; portanto, os serviços atendem aos requisitos subjacentes de uma fachada. Em outras palavras: enfrentado pelo problema de expor as interfaces subjacentes como uma interface unificada de "serviço", o padrão de fachada se ajusta aos requisitos e é usado para resolver o problema de serviço. A resposta para isso é yes.

Pergunta 2: é um Facade a Service? Os serviços são normalmente projetados como unidades de funcionalidade reutilizáveis, não associadas e com pouco acoplamento. Pensar na comunicação entre componentes é importante para os serviços, porque eles geralmente dependem de uma interface TCP/IP como SOAP ou WCF. Isso também significa que a funcionalidade geralmente é reescrita para se ajustar ao services paradigma mais de perto, que adiciona um requisito implícito impulsionado pelo desempenho para o padrão. As fachadas não possuem esse requisito extra. Em outras palavras: ma fachada não é um serviço =.

Em termos exatos, esses conceitos estão intimamente relacionados, mas não são os mesmos.

Mas podemos fazer melhor

Essa linha de pensamento levanta a questão se m serviço é uma versão estendida de uma fachada? É se um serviço atende a todos os requisitos de uma fachada e se estende além disso.

Se você ler atentamente a descrição do GoF, a resposta será sim, ou seja: se uma condição for atendida: O serviço deverá expor os subsistemas. Na realidade, acho que essa condição normalmente se mantém ou você está projetando demais os seus serviços - embora, estritamente falando, suponha que essa não seja uma restrição rígida.

1
atlaste

Uma interface serviço normalmente representa preocupações de negócios: execute algumas operações e/ou obtenha algumas informações. Não seria irracional para o provedor de serviços implementar seu serviço como uma fachada dos serviços internos de back-end - você nunca veria isso.

Seu fachada pode incluir algumas interfaces gerais, que podem incluir interfaces de serviço.

Por exemplo, você pode ter uma interface de serviço para uma conta bancária (operação: Banco transfere dinheiro) e uma API local para seus registros contábeis locais (eu transfiro dinheiro). Você pode introduzir uma fachada com uma operação "mover dinheiro" que usa a interface de serviço do banco e gerencia também o talão de cheques local.

1
Richard Sitze

Fachada e Camada de serviço tem uma espécie de semelhança, mas ambas têm dois distintos significados. Deixe-me explicar isso usando um exemplo simples.

Imagine que somos convidados a criar um novo aplicativo de negócios. Isso requer a criação de um aplicativo de check-in, mas com mais recursos de valor agregado e cartões de fidelidade.

Vamos dizer que o aplicativo deve oferecer suporte aos recursos de check-in do Facebook e do Foursquare, se o usuário desejar usar. Esse recurso é muito necessário porque alguns usuários relutam em usar vários aplicativos que executam a mesma função ou se livram da conectividade social.

para ter uma idéia de nível superior, consulte a API de amostra no seguinte link https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing

A API de check-in acima, localizada na fachada do ABC, é um exemplo para o uso do Facade.

Ele possui nossa API de serviço e também recursos de check-in no Facebook e no Foursqure com base na seleção do cliente. As APIs do Facebook e do foursqure podem ter implementações específicas (SOAP, Restful etc.) e requisitos de segurança (OAuth etc.) etc.

A satisfação de um desses requisitos de APIs (facebook, foursqure) precisa cumprir um conjunto diferente de tarefas. estes serão subsistemas diferentes em nosso requisito de check-in.

Portanto, o uso simplista da fachada é satisfazer vários subsistemas acionados por um método simples

Mas se considerarmos nossa própria API, que é a API de check-in localizada em MngCheckinSvc. Esta é uma API da camada de serviço . Essa é a API que contém os requisitos de check-in do nosso aplicativo. Essa é a API que fornece acesso público a partir do seu MngCheckinSvc para lidar com os requisitos de check-in do aplicativo.

Isso terá comportamentos internos complexos, mas a maioria deles será implementações lógicas específicas de aplicativos.

Essa API (MngCheckinSvc.checkin (....)) pode acessar um conjunto diferente de DAOs, APIs internas, outros serviços internos etc., a fim de realizar o check-in do comerciante no aplicativo.

0
Chamantha De Silva

É o "contexto" que importa. Fachada e Serviço não são conflitantes.

Primeiro, nunca ouvi falar de "Serviço" e "Fachada" no contexto do MVC.

Quando as pessoas falam sobre Serviço, trata-se mais de um sistema ou componente que fornece ações significativas para os negócios para o mundo exterior. Às vezes, você pode ver "Serviço" relacionado a "Unidade de trabalho" (e, portanto, transação).

O serviço também é usado no contexto de uma abordagem de aplicativo de camadas: temos o Serviço no topo do DAO, para o qual o Serviço acessará dados através do DAO e a lógica de negócios é colocada na camada Serviço, algo assim.

Fachada é geralmente usada no contexto do padrão de design, e o foco é "ocultar operações complicadas e expô-las como uma operação simples".

Fachada pode ser ou não ser um Serviço (uma operação na Fachada pode não representar uma Unidade de trabalho, mas ainda é uma fachada válida). Da mesma forma, um Serviço pode ou não ser uma Fachada (um Serviço pode não ocultar qualquer complicação operações, mas ainda é um Serviço).

Novamente, é tudo sobre o "contexto" que importa.

Por exemplo, quando você está falando sobre camadas de aplicativos, é simplesmente irracional dizer "XXX é uma fachada para acessar o DAO". Da mesma forma, se você estiver falando sobre "abordagem de design", é mais razoável dizer "XXX é uma fachada para vários back-end", em vez disso, chame-o de "Serviço" aqui (embora XXX seja realmente um Serviço).

0
Adrian Shum