私はC＃で作業を始めてから数ヶ月の間、私はもっと挑戦的で興味深いものを探しています。私はカスタムのVBスクリプトをサポートするmedia monkeyと呼ばれるメディアプレーヤーを使用しています。私は、現在の曲が再生されているdirにファイルを書き込んだり、以前にあったものを書き換えて新しい曲が再生されるたびに更新します。どのようなご提案ですか？
この情報をデータベースに追加し、これを記録し、おそらく私のホームページに情報を追加したいと思います。私はそれが働く方法をハックすることができますが、私は物事を行う "専門的な方法"が何であるかを知りたいと思います。
私は次のことを思いついて立ち往生しました。私は、データベースに接続するためにODBCドライバが必要です。これは乱雑に思えますが、Webサービスは機能しますか？それはどのように機能しますか？ VbScriptがdllファイルを呼び出して、別のサーバー上のデータを変更するためにWebサービスを呼び出すことはできますか？それは安全ですか？
多くのプロフェッショナルC＃アプリケーションはn層です。あなたのケースでは、あなたはおそらく、このようにそれをレイヤーになります。サーバー上で
：
-Databaseストア
-Databaseアクセス/ビジネス層を
（時々、二つの異なるコンポーネントに応じてどのように複雑なアプリがあります） - Webサービスのクライアントで
：
-Webサービスクライアントクライアント機能をサポートするための
-any他の層。
したがって、データベースストアは、OracleまたはMicrosoft SQL Serverの一部のテーブルのようなものになり、サーバー上に存在します。
データベースアクセス/ビジネス層は、データベースとの間でデータを取得し、データベースに格納するコードです。また、基本的にデータベースからのデータを表すプロパティを持つクラスであるビジネスオブジェクトを含む場合もあります。データアクセス層の利点は、データベースへの読み書きが特殊なコードを必要とすることがあり、そのコードをアプリケーションに散らばらせたくないということです。したがって、必要なデータをオブジェクトにロードするデータアクセスレイヤの関数を呼び出すことができます。そのため、残りのアプリケーションは通常の古い.NETオブジェクト/クラスとやりとりするだけです。これらはPOCOと呼ばれ、Plan Old CLR Objectのようなものです。もちろん、これには多くのバリエーションがあります。人々がデータベースアクセスのisalotingの問題に異なるアプローチを取っているからです。また、データベースが変更されるたびに、変更の破棄を最小限に抑える目的も果たします。データベースアクセスロジックはアプリケーション全体に振りかざされていないため、データベースが変更された場合（たとえば、新しい列をテーブルに追加したり、名前を変更するなど）、更新する必要がある場所が少なくなります。
場合によっては、ビジネスレイヤーが独自のレイヤーになり、アプリケーションの「ロジック」の大部分を含むことがあります。データアクセス層とWebサービス層の間に置かれます。サービス指向アーキテクチャー（SOA）の概念を使用すると、認証サービスとWeb要求処理サービスを持つことができます。これらのサービスは、常にインスタンス化され、要求を処理するのを待っているクラスによく似ています。あなたのウェブリクエスト処理サービスはリクエストを受け取り、最初にリクエストを尊重する前に認証サービスに電話してクレデンシャルを確認することができます。 SOAは、適切な場合にのみ使用すべきだと思うものの1つです。オブジェクト指向のテクニックを使用するだけで、同じ利点が得られます。必ずしもそうではありません。 SOAが適切に実行されるとスケーラビリティが向上するため、SOAが必要とする追加的なメリットを提供するかどうかによって大きく左右されます。
ウェブサービスは、ウェブからリクエストを受信し、解析/解釈し、ビジネスレイヤに呼び出してデータを更新または取得することによって、そのリクエストに対処します。
ここでのコンセプトは、あなたのサービスを利用してソングのアップデートを公開しているサービスのユーザーが多いということです。
クライアントには、メッセージへの要求の書式設定、Webサービスへの送信、およびWebサービスからのメッセージの取得に応答する「Webサービスクライアント」層があります。あなたは、Webサービス層にアプリケーションの「ロジック」をほとんど入れません。
これは多分あなた自身のために何かをしたいと思って以来、何をしたいのかというと過剰なものであり、非効率的ですが、それは多くのウェブサービスアプリケーションの基本的な解剖学であり、レイヤの目的はすべてデカップリングとシンプルさです。より多くのレイヤー/コンポーネントがアプリケーション全体をより複雑にする一方で、各コンポーネントがより簡単であることを意味します。これは、他のいくつかのコンポーネント（周囲のレイヤー）とだけ対話する1つのコンポーネントだけを扱うときに、問題を回避するのが簡単だということを意味します。したがって、いくつかのコンポーネントと多くのコンポーネントの間には慎重なバランスがあります。あまりにも少ないと、モノリシックになり、管理が難しくなります。あまりにも多く、彼らは複雑な方法で絡み合っています。私は、「クラスが大きくなり過ぎて複雑すぎる場合は、それをいくつかのクラスに分割する」という行に沿って何かを言ったと聞いています。本質的に、それはちょうどよいことのように聞こえるので、ちょうどそれの地獄のためのものを細分することを開始しないでください。コンポーネントを分割するかどうかを決定する前に、コンポーネントの複雑さを評価します。単純なケースでは、複数の目的に役立つレイヤーを用意しています。そのレイヤーをより速くし、全体のデザインをよりシンプルにするためです。要点は、適切なところにこれらの概念を適用することです。あなたは経験にふさわしいものを学び、「行うこと」によって最も多くを学ぶことができることを明らかに理解します。
"vbscriptでCOMコンポーネントを呼び出せますか？" COMサポートで.NET DLLをコンパイルできます。多くの古いものはCOM dllを呼び出すことができます。
私はGoogleで検索：VBScriptのDLL をし、この得た：VB Script and DLLs
を "安全が何をしていることですか？"あなたのWebサービスは、セキュリティに最も関心のある場所になります。セキュリティを念頭に置いて設計し、挫折しないようにするだけで安全です。私たちはすべて時にはネジを締めます。つまり、完全に安全であるという保証はありません。