Une architecture de niveau 3 (physique) est-elle inefficace?

Question

Note: Quand je parle de niveau, je veux dire un niveau physique. Beaucoup de questions sur ce site concernant les «niveaux» font référence à des couches logiques, ce qui n'est pas ce que je demande.

Je suis en train de concevoir une application utilisant une architecture standard "3 couches", avec des couches de présentation, de logique métier (BLL) et d'accès aux données (DAL). La technologie est WPF, C#, LINQ et SQL Server 2008. Ma question se rapporte à l'architecture physique de cette application.

Je peux placer le BLL/DAL dans une DLL standard qui est chargée et exécutée sur l'ordinateur de l'utilisateur, créant une architecture à deux niveaux - machine client et serveur de base de données. Mais il n'est pas trop difficile de transformer le BLL/DAL en un service WCF qui se trouve sur un serveur d'application et est appelé depuis la machine de l'utilisateur. Cela me donnerait une architecture à trois niveaux - machine client, serveur d'application et serveur de base de données.

Ma question est la suivante: quel est l'avantage d'utiliser une architecture à 3 niveaux? On m'a souvent dit que 3 niveaux ajoutent de l'évolutivité, mais ce n'est pas immédiatement évident pour moi. Et vous allez sûrement prendre un coup de performance avec les mêmes données qui doivent faire deux sauts sur le réseau - du serveur de base de données au serveur d'applications, puis du serveur d'applications à la machine client.

J'apprécierais les conseils d'architectes et de développeurs expérimentés.

Answer 1

Cela dépend de l'utilisation de votre application et de vos besoins de sécurité. Si votre application est utilisée sur Internet et que vous stockez quelque chose de potentiellement sensible, il est fortement recommandé d'ajouter la suppression physique pour la base de données. Jamais, jamais laisser quelqu'un de l'extérieur sur une machine avec un accès direct à votre base de données. Les gens peuvent et vont tenter de briser votre sécurité pour une meilleure raison qu'ils n'ont rien de mieux à faire.

L'évolutivité peut aussi être un facteur, à la fois devant la couche de présentation (devant les serveurs Web) et dans la base de données. Placer un équilibreur de charge devant la couche de présentation permet d'acheminer les demandes entrantes vers un tableau de machines pouvant être gérées indépendamment. Les machines peuvent être ajoutées à la piscine en cas de besoin et retirées pour maintenance. Placer les équilibreurs de charge entre les autres couches peut avoir le même impact. L'idée est de fournir un environnement back-end souple et dynamique pouvant être ajusté en fonction de la demande.

Answer 2

Cela peut être. Cela dépend de ce qui a été mis en place et comment.

La force motrice nécessaire à la création d'une architecture physique à 3 niveaux n'est pas nécessairement liée aux performances.

La raison pour laquelle l'évolutivité est citée est qu'un service peut s'exécuter sur une batterie de serveurs, mais les clients ne le savent pas. La taille de la batterie de serveurs peut être augmentée pour répondre à la demande si l'architecture a été conçue pour la prendre en charge.

Answer 3

L'inefficacité est dans l'oeil du spectateur. Par exemple, tout ce qui se passe sur le client peut augmenter l'encombrement mémoire ou les besoins CPU/réseau des ordinateurs clients. Si ce travail peut être déchargé sur un serveur/une batterie de serveurs, vous pouvez éviter d'effectuer des mises à niveau matérielles de PC clients uniquement pour exécuter votre logiciel. Si plus de ressources ou de mises à niveau sont nécessaires, elles peuvent être ajoutées/effectuées dans le niveau de la logique métier sans impact sur les clients. De plus, avoir la logique métier sur son propre niveau peut être plus efficace plus tard (du point de vue du développement logiciel) lorsque vous devez exposer certaines fonctionnalités de votre application dans un système Web ou un complément Outlook. ou une application iPhone.Vous ne voulez pas avoir à mettre à jour tous ces systèmes chaque fois que la logique métier change légèrement.

de sécurité peut-être mieux que vos utilisateurs ne ont pas besoin d'un accès direct au serveur de base de données, ils sont isolés par le serveur d'applications.

Il vous oblige aussi à penser à votre application de manière modulaire avec des interfaces bien définies qui peuvent avoir des avantages architecturaux à la conception de votre application.

Answer 4

Chaque fois que vous vous posez la question «Est-ce que X est inefficace? vous devriez, immédiatement, vous poser trois questions précurseurs:

1. Par « inefficace » quelle ressource pensez-vous qu'il devrait utiliser efficacement et peut ne pas être? Temps? Espace? Bande passante? Heures de développement?

2. Pourquoi ça peut vous faire? Non, sérieusement: Si vous allez passer une minute à répondre à cette question, il doit y avoir une raison. Quelle est cette raison?

3. Par rapport à quoi?

En ce qui concerne vos commentaires sur l'évolutivité: Pendant un certain temps, j'ai eu la responsabilité regrettable de maintenir un système dont l'architecte qui avait été dit que la réduction d'allers-retours à la base de données serait une application évolutive. Il a pris cette perspicacité et a couru avec elle. Vous pouvez lire sur ce projet here. Il me semble que j'aurais dû mentionner qu'à aucun moment au cours de toute la durée de vie de cette application, il n'y avait plus de quatre utilisateurs connectés simultanément.

Answer 5

principal avantage de 3t applications décrites comme vous l'avez fait est pas l'évolutivité. La maintenabilité peut-être.

Afin de rendre votre architecture évolutive vous avez besoin d'une technologie plus que vous ne l'avez pas mentionné. - vous avez besoin de services. Je suggérerais WCF.

Rendre votre service BLL WCF (ou plusieurs services) rendrait votre application beaucoup plus efficace et évolutive, permettant à votre BLL de fonctionner sur des machines différentes/multiples.