Bonjour, j'ai besoin de votre aide afin de valider les inconvénients et avantages d'un modèle de structure d'accès aux données en .Net.

Le modèle vise à régler un problème d'accès aux données afin de permettre à une application de vivre dans une DMZ ou un WAN et avoir accès aux données d'un LAN. (Pour ceux qui ne connaissent pas ces termes, c'est simple, permettre à un logiciel dans une zone publique d'accéder à un serveur SQL dans une zone privé comme un réseau local d'entreprise)

Afin de faire fonctionner mon modèle j'ai établi les étapes suivantes et j'aimerais que vous m'aidiez à le valider afin de donner un peu de poids à mon argumentation envers mes dirigeants intransigeants qui ne savent pas vraiment vers quoi aller comme solution :

Survol

Utilisation de webservice ou de couche physiques pour l'àccès aux données par exemple :

Application dans la DMZ -> API en mémoire -> Web Service dans le LAN -> Couche d'accès physique en mémoire -> SQL Server

Cette technique si bien implanté peu être horriblement versatile et proposer un accès à plusieurs web service en chaine, donc si un webservice est public, il pourrait utiliser le web service privé pour aller chercher ses données.
Vous voyez ou je veux en venir? J'espère...

Présentation du modèle par couche

Première couche : Visuel/Applicatif (Presentation layer)
Nous avons ici plusieurs logiciels qui ont tous une fonction particulière mais opérant sur les même données de façon différentes.

Deuxième couche : Logique d'entreprise (Business layer)
Ici je prévois faire un simple système de classe qui gère tous les éléments de la base de données comme les employés, les transactions, la facturation et autres. Ce layer est complètement intégré et contrôle les accès par login et logout ainsi que plusieurs autres méchanismes...

Troisième couche : Logique d'accès aux données (Data layer)

C'est ici que ca devient compliqué. Afin d'éviter de forcer une entreprise d'utiliser un WebService surtout si elle n'en à pas besoin, je veux faire en sorte que le layer devienne en fait une interface pour deux sous modules.

L'interface d'écrirait les méthodes d'accès aux données qu'elle que soit la vraie méthode d'accès. Ensuite, en suivant ce modèle d'interface, je créerais deux data layer, un pour accéder directement à la base de données et un pour accéder à un service web.

Résultat

Quelqu'onque application devrait donc utiliser l'api de la deuxième couche en tout temps afin de contrôller les accès aux données. Par la suite cet api utilise le iDataLayer (Interface) de son choix selon la config pour aller chercher l'information.

Dans le cas que le iDataLayer est le webservice, est bien, la chaine recommence et le WebService utilise un API business afin de se connecter à la prochaine source valable. Ce nouveau noeud dans l'api pourrait être a nouveau configuré pour utiliser un Web Service qui en retour créera un troisième noeud d'API business... Encore ici le troisième noeud pourrait être configuré pour l'accès à une quatrième noeud de web service si l'on veut, ou pourrait à ce point se connecter sur l'autre iDataLayer qui est celui d'accès à la base de données.

Ceci permettrait donc (avec un impact notable sur la vitesse de travail bien évidement) permettre à quiquonque d'installer une chaine de web service qui communiquent ensembles et se relais le travail pour aller chercher l'information. Donc, autant de pare-feu ou de phénomène d'intrusion qui seraient disponibles pourrait donc, de manière sécurisé sous SSL être contournées sécuritairement. Et si l'utilisateur ne désire pas utiliser les webservice, il pourrait configurer son API de son logiciel pour se connecter directement au iDataLayer de la base de données et voila donc le travail...

Qu'est-ce que vous en pensez? Donnez moi vos commentaires les plus pertinents ainsi que des expériences si possible car c'est présentement une crise solide ici...

Les dirigeants veulent absolument fermer les communications directes entre les logiciels publics et la base de données privé afin de rendre le tout sécuritaire. Pour se faire, la seule solution qu'ils croient enviables est la création d'un logiciel de synchronisation. Dans le département de programmation nous sommes tous contre cette idée qui ne nous ammeneras que du trouble constant...