Question

Nous construisons une application d'entreprise dans laquelle nous intégrerons plusieurs plates-formes pour les interfaces utilisateur (par exemple, une application Web ASP.net, une application Windows et un jour, des applications mobiles) et plusieurs plates-formes pour les bases de données principales (par exemple, SQL Server, XML, etc.). Oracle). Une autre nécessité est que ces bases de données principales soient soit centralisées et accessibles via le Web, soit localisées sur l’ordinateur client et parfois synchronisées sur le serveur central.

Quelqu'un peut-il donner des conseils sur la manière de résumer la couche d'interface utilisateur & amp; la couche de données pour créer plus simplement une adaptabilité plug-and-play entre les différentes interfaces utilisateur et les différents choix de bases de données? Par exemple: dans un cas, une application Web peut s'exécuter sur un serveur centralisé via Internet et des machines distantes peuvent exécuter des copies localisées via une application Windows. À intervalles réguliers, nous voudrions que toutes les machines soient synchronisées de manière à pouvoir toutes avoir des données en temps quasi réel.

Nous avons également besoin de conseils sur la gestion des différentes chaînes de connexion concernées, de sorte que le seul paramètre à modifier dans une application donnée soit "local". ou "à distance", ce qui déterminerait alors la chaîne de connexion nécessaire.

Était-ce utile?

La solution

Abstrait de la couche de présentation est un concept assez facile une fois que vous avez maîtrisé l’architecture n-tier. Concentrez-vous simplement sur la différenciation de la "logique de domaine". à partir de "logique d'application". La logique de domaine est commune à vos différentes plates-formes et la logique d'application est spécifique à chaque plate-forme. Par exemple, la validation des données est une logique de domaine (bien que ce soit bien quand on peut le faire en front-end, ce qui rend les choses plus complexes, mais travaillez avec moi ici ...) et de décider de l'URL à rediriger après une action est l'application logique. Assurez-vous de placer la logique de votre domaine à un niveau utilisable par toutes les plates-formes et veillez à ne placer aucune logique d'application dans votre couche de domaine.

L'autre moitié de votre question semble être votre objectif principal, mais je voudrais demander quelques éclaircissements, car je peux discerner deux questions essentielles différentes.

  1. J'espère que vous n'allez pas chercher le "Saint Graal". de l'indépendance de la base de données. C’est toujours un objectif ambitieux défini lors de la phase de conception, qui n’est presque toujours pas nécessaire, à peu près à chaque fois.

    Si ce n'est pas ce que vous recherchez, je vous suggérerais alors de savoir quels objets sont enregistrés dans quel support de persistance, d'éviter la complexité liée à la flexibilité et de coder simplement les chemins verticaux transmettre le plus possible. IE ne code pas d'éléments supplémentaires dans une classe métier qui stocke ses données dans Oracle pour vous permettre de les placer dans SQL Server "à un moment donné dans l'avenir". (Je suis revenu à la ronde pour revenir à l'indépendance de la base de données, n'est-ce pas?)

  2. La question de la mise en cache locale des données pour améliorer les performances de certaines plates-formes est spécifique à ces plates-formes et je vous suggère de vous pencher sur les clients intelligents et sur le cadre / les conseils de mise en cache de l'équipe MS P & amp; P. Je travaille assez exclusivement sur le Web depuis quelques années, mais en 05/06, c’était plutôt bon et ils ont beaucoup travaillé sur leur produit Smart Client entre-temps.

Autres conseils

Je voudrais utiliser le modèle de fournisseur pour établir les connexions à la base de données dans votre application.

Je commencerai par examiner les exemples et les détails fournis dans le bloc d'application de données Microsoft. Je pense que cela vous aidera à vous frayer un chemin.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top