Viele professionelle C# -Apps sind N-Tier. In Ihrem Fall, würden Sie wahrscheinlich es wie diese Schicht:
Auf dem Server:
-Database Shop
-Database Zugang/Geschäftsschicht (manchmal zwei verschiedene Komponenten, je nachdem, wie komplex die App)
- Web Service
auf dem Client:
-Web-Service-Client
-Alle andere Schichten Client-Funktionalität zu unterstützen.
So wäre der Database Store so etwas wie einige Tabellen in einem Oracle oder Microsoft SQL Server, und würde auf Ihrem Server.
Datenbankzugriff/Business-Schicht ist Ihr Code, der Daten von Ihrer Datenbank abruft und speichert. Es kann auch Business-Objekte enthalten, bei denen es sich im Grunde um Klassen handelt, deren Eigenschaften Ihre Daten aus Ihrer Datenbank repräsentieren. Der Vorteil der Datenzugriffsschicht besteht darin, dass das Lesen und Schreiben in eine Datenbank manchmal spezialisierten Code erfordert, und Sie möchten nicht, dass dieser Code durch Ihre Anwendung gestreut wird. Stattdessen können Sie Funktionen in Ihrer Datenzugriffsebene aufrufen, die benötigte Daten in Objekte laden, sodass der Rest Ihrer Anwendung nur mit einem regulären alten .NET-Objekt/einer Klasse interagiert. Diese heißen POCOs, was für so etwas wie Plan Old CLR Object steht. Es gibt natürlich viele Variationen darüber, da die Leute verschiedene Ansätze für das Problem des isalotierenden Datenbankzugriffs gewählt haben. Außerdem dient es dazu, Unterbrechungsänderungen zu minimieren, wenn sich die Datenbank ändert. Da die Datenbankzugriffslogik nicht über die gesamte App verteilt ist, müssen weniger Stellen aktualisiert werden, wenn sich die Datenbank ändert (z. B. Hinzufügen neuer Spalten zu einer Tabelle oder Ändern eines Namens).
Manchmal ist die Business-Schicht eine eigene Schicht und würde den Großteil der "Logik" der Anwendung enthalten. Es würde zwischen den Datenzugriffs- und Web-Service-Schichten sitzen. Unter Verwendung von Konzepten der Service Oriented Architecture (SOA) verfügen Sie möglicherweise über einen Authentifizierungsdienst und einen Webantragsverwaltungsdienst. Diese Dienste ähneln stark einer Klasse, die immer instanziiert ist und dort auf die Verarbeitung von Anforderungen wartet. Ihr Webantragsverwaltungsdienst würde eine Anforderung annehmen und möglicherweise zuerst den Authentifizierungsdienst aufrufen, um die Anmeldeinformationen zu überprüfen, bevor die Anforderung erfüllt wird. SOA ist eines dieser Dinge, von denen ich denke, dass sie nur verwendet werden sollten, wenn es angemessen ist. In einigen Fällen, die nur objektorientierte Techniken verwenden, erhalten Sie dieselben Vorteile. Nicht immer aber. SOA ist, wenn sie richtig gemacht wird, skalierbarer, es kommt also wirklich darauf an, ob Ihnen SOA zusätzliche Vorteile bietet, die Sie benötigen.
Der Webservice ist zuständig für das Empfangen von Anfragen aus dem Internet, das Parsen/Interpretieren dieser Anfragen und das Einwirken auf diese Anfragen, indem Anrufe in Ihre Business-Schicht zum Aktualisieren oder Abrufen von Daten getätigt werden.
Also das Konzept hier wäre, dass Sie viele Benutzer Ihres Dienstes haben könnten, die ihre Song-Updates über Ihren Service veröffentlichen.
Ihr Client verfügt über einen "Web-Service-Client", der für die Formatierung von Anforderungen in Nachrichten, das Senden an den Webdienst und das Abrufen von Nachrichten vom Webdienst verantwortlich ist. Sie würden sehr wenig Anwendungslogik in Ihre Web-Service-Schicht einfügen.
Jetzt ist all dies wahrscheinlich übertrieben und ineffizient für das, was Sie tun möchten, da Sie nur etwas für sich selbst wollen, aber es ist die grundlegende Anatomie vieler Webservice-Anwendungen und wäre eine gute Lernübung. Der ganze Zweck der Schichten ist Entkopplung und Einfachheit. Während mehr Schichten/Komponenten die Anwendung insgesamt komplexer machen, bedeutet dies, dass jede Komponente einfacher ist. Dies bedeutet, dass es einfacher ist, sich mit Problemen zu befassen, wenn Sie nur mit einer Komponente arbeiten, die nur mit ein paar anderen Komponenten (der umgebenden Schicht) interagiert. Es gibt also ein sorgfältiges Gleichgewicht zwischen wenigen Komponenten und vielen Komponenten. Zu wenig und sie werden monolithisch und schwer zu verwalten. Zu viele, und sie werden auf komplexe Weise miteinander verflochten. Ich habe gehört, dass es etwas in der Art von "Wenn eine Klasse zu groß und zu komplex wird, dann teilen Sie sie in ein paar mehr Klassen" sagte. Im Wesentlichen, fangen Sie nicht an, Sachen für den Teufel davon einzuteilen, nur weil es wie das Richtige zu tun klingt. Bewerten Sie, wie komplex Ihre Komponente sein wird, bevor Sie entscheiden, ob Sie sie aufteilen möchten. Manchmal haben Sie für einfache Fälle eine Ebene, die mehr als nur einen Zweck erfüllt, um schneller fertig zu werden und das Gesamtdesign zu vereinfachen. Der Punkt ist, diese Konzepte gegebenenfalls anzuwenden. Sie werden lernen, was mit Erfahrung angemessen ist, und Sie verstehen offensichtlich, dass Sie am meisten lernen können, indem Sie "tun".
"Kann VBScript eine COM-Komponente aufrufen?" Sie können .NET DLLs mit COM-Unterstützung kompilieren. Viele ältere Dinge können COM dlls aufrufen.
Ich googeln: Vbscript dll und bekam diese: "Ist das sicher zu tun" VB Script and DLLs
Ihr Webservice ist der Ort, an dem Sie sich am meisten mit Sicherheit beschäftigen würden. Es ist nur sicher, wenn Sie mit Sicherheit planen und nicht vermasseln. Wir alle vermasseln manchmal, was bedeutet, dass es keine Garantie dafür gibt, dass es vollkommen sicher ist.