3 層と 2 層のアプリケーションの開発 [終了]
-
21-12-2019 - |
質問
私が理解した限りでは、3 層アーキテクチャとは、懸念事項ごとに個別のプロジェクトを意味すると言えます。UI層、ビジネス層、データ層です。UI は BL と通信し、BL は DB と通信し、その逆も同様です。これは保守性の点で優れており、懸念事項を分離するという考え方も合理的です。しかし一方で、階層は層とは異なります。つまり、層はマシン/ネットワークに直接関係しています。2 層という場合、通常はクライアント マシンとデータベース サーバー マシンのことを指します。3 層というと、一般的にクライアント マシン、アプリケーション サーバー マシン、データベース サーバー マシンのことを指します。したがって、これらの情報に基づいて、3 層アーキテクチャを使用する 2 層アプリケーションの開発が可能になります。
これまでは 3 層で開発してきましたが、3 層で開発するか 2 層で開発するかを決める時期が来ました。現場には Windows フォーム プロジェクトがあり、約 150 のクライアントと 100 台のハンド ターミナルが Windows フォーム プロジェクトを使用して Web サービス経由で通信します。ハンドターミナルでは、3 層を使用するのが最適なソリューションであることは明らかですが、Windows 7 上で実行される Windows クライアントの場合、1 つのアプリケーション サーバーを介してデータベースと通信するか、データベースに直接接続するかを決定するのは困難です。
ここでの主な質問は、2 層に比べて 3 層アーキテクチャの利点は何かということです。私にとって、層が 1 つ増えるということは、常に稼働しておく必要があるサーバー/ホスト/マシンが 1 つ増えることを意味し、オーバーヘッドになる可能性があります。
最適な階層アーキテクチャを選択する際の参考にしてください。
解決
「3 Tier」(クライアント、アプリケーションサーバ、およびデータベースサーバ)のみを使用すると、アプリケーションサーバでメジャータスクを実行することをお勧めします。それ以外の場合は、データベースプラットフォームを実行できるリソースを使用できます。。たとえば、アプリケーション(ビジネスレイヤ)とデータベースサーバ(データ層)の間で実行されている接続プーリングまたは接続管理ソフトウェア。
他のヒント
次のコンポーネントがあるとします。UI
, Common
, Biz
, DAL
2 層または 3 層のアプリケーション開発では、 UI
そして Common
の上 client
そして Common
, Biz
, DAL
の上 server
(共通が両方にデプロイされていることに注意してください) そして、次の方法で BIZ に接続しようとします。 .Net Remoting
または WCF
そして最後に、DB は最後の層のサーバーまたは他のサーバー上に配置できます。
これがお役に立てば幸いです