De nombreuses applications professionnelles C# sont à n-tier. Dans votre cas, vous couche probablement comme ceci:
Sur le serveur:
-Database magasin
-Database Accès/couche d'affaires (parfois deux composants distincts, en fonction de la complexité de l'application est)
- Web service
Sur le client:
-Web service à la clientèle
-Tout d'autres couches pour soutenir la fonctionnalité de client. Donc le magasin de base de données serait quelque chose comme des tables dans un serveur Oracle ou Microsoft SQL, et serait sur votre serveur. Base de données Access/Business layer serait votre code qui récupère et stocke des données dans/de votre base de données. Il peut également contenir des objets métier, qui sont essentiellement des classes ayant des propriétés représentant vos données à partir de votre base de données. L'avantage de la couche d'accès aux données est que parfois lire et écrire dans une base de données peut nécessiter du code spécialisé, et vous ne voulez pas que ce code soit diffusé dans votre application. Ainsi, vous pouvez appeler des fonctions dans votre couche d'accès aux données qui chargent les données nécessaires dans les objets, de sorte que le reste de votre application interagit simplement avec un objet/classe .NET ancien. Ceux-ci sont appelés POCOs, qui signifie quelque chose comme Plan Old CLR Object. Bien entendu, il y a beaucoup de variations, car les gens ont adopté des approches différentes du problème de l'accès à la base de données. En outre, il sert à minimiser les changements de rupture chaque fois que la base de données change. Comme la logique d'accès à la base de données n'est pas répandue dans toute l'application, il y a moins d'endroits à mettre à jour si la base de données change (comme ajouter de nouvelles colonnes à une table ou changer un nom).
Parfois, la couche de gestion sera sa propre couche et contiendra la majeure partie de la «logique» de l'application. Il se situerait entre les couches d'accès aux données et de services Web. À l'aide des concepts de l'architecture SOA (Service Oriented Architecture), vous pouvez disposer d'un service d'authentification et d'un service de gestion des requêtes Web. Ces services ressemblent beaucoup à une classe qui est toujours instanciée, attendant de traiter les requêtes. Votre service de gestion des requêtes Web prend une requête et peut-être appelle d'abord le service d'authentification pour vérifier les informations d'identification avant d'honorer la demande. La SOA est l'une de ces choses que je pense ne devrait être utilisée que lorsque c'est approprié. Dans certains cas, l'utilisation de techniques orientées objet vous donnera les mêmes avantages. Pas toujours cependant. La SOA, quand elle est bien faite, est plus évolutive, donc cela dépend si la SOA vous offre des avantages supplémentaires dont vous avez besoin.Le Webservice serait chargé de recevoir des demandes du Web, de les analyser/interpréter et d'agir sur ces demandes en effectuant des appels dans votre couche de gestion pour mettre à jour ou récupérer des données.
Donc le concept ici serait que vous pourriez avoir de nombreux utilisateurs de votre service qui publient leurs mises à jour de chansons via votre service. Votre client disposerait d'une couche "client de service Web" qui serait responsable du formatage des demandes en messages, de leur envoi au service Web et de la récupération des messages du service Web. Vous mettriez très peu d'application "logique" dans votre couche de service Web. Maintenant tout cela est probablement exagéré et inefficace pour ce que vous voulez faire puisque vous voulez juste quelque chose pour vous-même, mais c'est l'anatomie de base de beaucoup d'applications webservice et serait un bon exercice d'apprentissage. Le but entier des couches est le découplage et la simplicité. Bien que plus de couches/composants rendent l'application globalement plus complexe, cela signifie que chaque composant est plus simple. Cela signifie qu'il est plus facile d'envelopper votre tête autour des problèmes quand vous ne traitez qu'un composant qui interagit avec seulement quelques autres composants (la couche de sourds). Il y a donc un équilibre prudent entre quelques composants et de nombreux composants. Trop peu et ils deviennent monolithiques et difficiles à gérer. Trop, et ils s'entremêlent de manière complexe. J'ai entendu dire quelque chose comme: «Si une classe devient trop grande et trop complexe, alors divisez-la en quelques classes de plus». En substance, ne commencez pas à subdiviser les choses pour le plaisir juste parce que cela semble être la bonne chose à faire. Évaluez la complexité de votre composant avant de décider si vous voulez le diviser. Parfois, pour les cas simples, vous avez une couche servant à plus d'un but, pour le faire plus rapidement et rendre la conception globale plus simple. Le point est, appliquer ces concepts le cas échéant. Vous apprendrez ce qui est approprié avec l'expérience, et vous comprenez évidemment que vous pouvez apprendre le plus en «faisant».
"Est-ce que vbscript peut appeler un composant COM?" Vous pouvez compiler des DLL .NET avec le support COM. Beaucoup de choses plus anciennes peuvent appeler des DLL COM.
Je googlé: dll vbscript et obtenu ceci: "Est-ce sécuritaire de le faire" VB Script and DLLs
Votre webservice sera où vous seriez le plus concerné par la sécurité. C'est sûr seulement si vous concevez avec la sécurité en tête et ne bousillez pas. Nous faisons tous des bêtises parfois, ce qui signifie qu'il n'y a aucune garantie qu'il soit parfaitement sécurisé.