Quelle est la différence entre les modèles de conception de façade et de passerelle?
ou façade == Passerelle?
En examinant Facade dans le livre du GoF et le lien dans une autre réponse à Martin Fowler's Gateway, il semble que leur objectif soit dans des directions opposées.
La façade fournit une vue uniforme simple des composants internes complexes à (un ou plusieurs) clients externes;
La passerelle fournit une vue uniforme simple des ressources externes aux composants internes d'une application.
Cette distinction nous permet de nous concentrer sur ce qui est le plus important dans une conception:
Avec la façade, le système externe est notre client; il est préférable d'ajouter de la complexité face à l'intérieur si cela rend l'interface externe plus simple.
Avec la passerelle, le système interne est notre client; donnez-lui toute l'aide que nous pouvons, même si les externes sont plus complexes.
Ces deux modèles sont très similaires dans la façon dont ils servent à la fois d'enveloppe à quelque chose . La différence se situe dans le contexte : la façade se dresse au-dessus d'un groupe de sous-systèmes, tandis que la passerelle peut se tenir debout sur n'importe quelle fonctionnalité. De ce point de vue, pour moi Facade est le cas concret de Gateway (pas opposé).
La façade est appliquée lorsque nous pensons que travailler avec des sous-systèmes est complexe o si nous voulons regrouper plusieurs appels de sous-système en une seule exécution [méthode]. Cependant, cela ne signifie pas nécessairement que les sous-systèmes ne sont pas accessibles ou qu'ils sont suffisamment complexes. Cela signifie simplement que nous avons des sous-systèmes.
La passerelle est appliquée lorsque nous voulons envelopper certaines choses et les exposer de différentes manières. La passerelle peut envelopper non pas un sous-système, mais juste une fonctionnalité relativement complexe. La passerelle est un modèle général qui peut être considéré comme une base pour les modèles Facade, Proxy et autres.
Si un exemple est encore nécessaire pour la clarification:
Facade peut calculer la solvabilité d'un client en interrogeant le sous-système de vérification des comptes, le sous-système de comptes de crédit, le sous-système d'épargne et le sous-système de back-office (je suppose que j'ai vu un exemple similaire dans les livres GOF).
class MortgateFacade {
bool IsCreditWorth(string customerName) {
return !_checkingAccSystem.HasNegativeBalance(customerName) && !_creditAccSystem.HasNegativeCredit(customerName) && !_backOfficeSystem.IsInBlackList(customerName);
}
}
La passerelle peut interroger la table de base de données et renvoyer le client par ID. (Oui, c'est simple!)
class CustomersGateway {
Customer GetCustomer(int id) {
return _db.ExecuteOne("SELECT TOP 1 FROM CUSTOMERS WHERE CUSTOMER_ID="+id).AsCustomer();
}
}
[C'est évidemment un pseudo-code]
L'intention de la façade est donnée par http://c2.com/cgi/wiki?FacadePattern as
Fournissez une interface unifiée à un ensemble d'interfaces dans un sous-système. La façade définit une interface de niveau supérieur qui facilite l'utilisation du sous-système. Cela peut être utilisé pour simplifier un certain nombre d'interactions d'objets complexes en une seule interface.
L'accent est mis ici sur la conception d'une interface qui cache la complexité, et je pense que l'idée clé est de masquer plusieurs interactions fines dans une seule interaction plus utilisable. Par conséquent, l'objectif de Facade est orienté client.
Le modèle de passerelle n'est pas l'un des modèles GOF d'origine, et je le vois plus comme un modèle d'intégration d'entreprise, c'est-à-dire à un niveau plutôt plus élevé que la façade. Voir Fowler définition
Je considère que la passerelle consiste principalement à cacher la complexité technologique plutôt que la complexité de l'interface - à cacher les détails de la connexion aux ordinateurs centraux et aux systèmes externes. En fait, je m'attends souvent à ce que la passerelle devienne quelque chose comme un routeur de demande, peut-être même en sélectionnant différents systèmes backend sur la base des détails de la demande. Je vois donc Gateway comme étant concentré sur les choses vers lesquelles il est une passerelle.
Évidemment, de manière informelle, une passerelle est une façade, en ce sens qu'elle cache des détails, mais je pense que lorsque vous implémentez une façade GOF et une passerelle Fowler, vous finissez par faire des choses très différentes.
Je pense que Gateway est un cas spécifique de Façade - une façade sur un système externe.
Voici la citation directe du livre de Fowler:
Alors que Facade simplifie une API plus complexe, elle est généralement effectuée par le rédacteur du service pour une utilisation générale. Une passerelle est écrite par le client pour son usage particulier. De plus, une façade implique toujours une interface différente de ce qu'elle recouvre, tandis qu'une passerelle peut copier entièrement la façade enveloppée, utilisée à des fins de substitution ou de test.
[Chapitre 18]
Cela pourrait être quelque peu simplifié, mais voici mon point de vue.
- Lorsque vous utilisez le modèle de façade, vous fournissez l'interface que d'autres peuvent utiliser pour parler à votre application. Exemple: Vous avez implémenté une application qui a plusieurs "modules", pour faciliter l'accès aux "modules" vous créez une façade pour faciliter l'interaction avec les modules ... un seul point de contact.
- Lorsque vous utilisez le modèle de passerelle, vous encapsulez une partie externe que vous souhaitez utiliser. Exemple: vous souhaitez utiliser la journalisation mais ne voulez pas vous lier à un cadre de journalisation spécifique, dans ce cas, vous pouvez définir votre passerelle qui définit les fonctionnalités que vous souhaitez utiliser et laisser la passerelle gérer l'interaction avec le cadre de journalisation que vous souhaitez utiliser. Cela facilitera la modification du cadre de journalisation à l'avenir.
En termes simples, Facade est un modèle de conception tandis que Gateway est un modèle architectural.
Application Gateway, par exemple, est un modèle d'architecture d'infrastructure. Le nœud réside dans DMZ et isole les nœuds internes des clients externes qui ne peuvent se connecter qu'à la passerelle d'application.
Lorsque vous pensez aux modèles d'architecture, pensez aux nœuds. Lorsque vous pensez aux modèles de conception, pensez aux classes/objets.
Le nœud est une abstraction de: périphérique - matériel informatique et logiciel système - par ex. OS, plate-forme/framework, etc. Le logiciel système est "attribué" à l'appareil. Node "encapsule" à la fois le périphérique et le logiciel système et est lié aux autres nœuds constituant l'architecture.
La passerelle est un nœud qui isole les nœuds de serveur des nœuds clients - le nœud client ne peut pas se connecter directement à un nœud de serveur. La passerelle reçoit la connexion, puis établit elle-même la connexion au nœud de destination.
Façade utilisée pour travailler avec certains graphiques d'objets comme avec un seul objet et passerelle pour connecter deux modules/systèmes différents.
Un motif de façade la valeur principale est de ' simplifier ' l'utilisation des composants internes (derrière la façade). Il se pourrait qu'un point d'entrée ou une fonction dans la façade utilise plusieurs fonctions des composants internes. Si une passerelle apporte la même valeur de ' simplifiant ' l'utilisation des API ou des composants derrière elle, elle pourrait être considérée comme une façade. Dans d'autres situations, une passerelle peut être simplement un middleware, un adaptateur, un wrapper ou un élément de transfert d'appel de l'architecture. Ou une passerelle peut porter plusieurs chapeaux, comme simplifier quelques flux, transférer certains appels tout en agissant en tant que middleware d'authentification ou d'autorisation en parallèle. Ainsi, la passerelle IMHO est un modèle très abstrait qui pourrait englober un ou plusieurs modèles structurels spécifiques tels que façade, adaptateur, wrapper, décorateur ou middleware, etc. .
Martin Fowler la définition de passerelle est de nature étroite (au moins celle ici ) et est plus proche de Passerelles API agissant comme des décorateurs de format .
En ce qui concerne la mise en œuvre, il n'y a pas de limite à ce qu'une passerelle pourrait et ne pourrait pas faire. C'est pratiquement une application qui lui est propre et pourrait offrir n'importe quelle fonctionnalité.
Pour répondre à votre question, je ne dirais pas que Facade == Gateway, mais que Facade≈Gateway. J'entends par là qu'ils sont à peu près égaux, comment ils diffèrent n'est pas apparemment clair sur la base des opinions divergentes ci-dessus.
Vous devez vous rappeler que l'un des éléments clés des modèles de conception et de la terminologie en général est d'aider à communiquer plus facilement vos idées. Cela étant dit, si vous parlez toujours en termes de façade, vous aurez plus de chances d'être compris car c'est le terme le plus utilisé.
J'ai tendance à penser à de nombreux modèles comme à des cas particuliers de modèle de proxy, et je ne m'inquiète pas beaucoup de celui-ci en particulier.
C'est à dire:
Facade est votre simple proxy pour un tas de classes compliquées.
L'adaptateur est un proxy pour des parties du système avec des interfaces incompatibles comme celle dont nous avons besoin en ce moment
etc...
À en juger par ce que j'ai trouvé sur une recherche Google pour "modèle de passerelle", il semble que Gateway == Proxy: D