9
実際に3層アーキテクチャが必要な例は何ですか？ 3層アーキテクチャを使用しているアプリケーションのほとんどは、2層アーキテクチャを使用して実行できますか？3階層アーキテクチャと2階層アーキテクチャ
注：私は3層アーキテクチャの価値を見出そうとしていますが、3層が現在2層で実行できるアプリケーションのほとんどを感じているので、私は絶対に必要な例を探しています3その必要性に例外はありません。
A
答えて
6
階層化されていない（分離/展開の物理的な単位）ではなく、階層化された（論理的な分離単位）ということを推測しています。階層化されたシステムの例は、第3層のデータベースからデータを引き出すウェブページ（別の層）を配信するウェブサーバ（1層）である。
レイヤードアーキテクチャの通常の目的は、責任を分けることです。これには2つの主な利点があります（他のものの中でも）。
まず、責任が泥沼にならないようにデザインが明確になり、コードを読みやすく、理解し、維持しやすくなります。
二次的には、ページが表示されるだけでなくビジネスロジック（恐怖データアクセスの恐怖）を処理しているWebアプリケーションの場合など、重複を減らす可能性があります。複数のページが同じまたは同様のことをしようとしています。
あなたはソフトウェアの任意の部分を設計することはできますが（他の方法もありますが）、些細なこと以外は何かのために、結果が維持できない混乱になります。
-1
あなたはウェブサイトを持っていれば...おそらくいくつかのJavascriptコードを持っていますので、一度はサーバーでビジネスロジックを持ち、物事を保存するデータベースを持っています。それは私の意見では3つの層です。もちろん、データベースに格納されているprocsを使用し、ビジネスロジック層をスキップすることができますので、必要に応じて2つの層を持つWebサイトを構築することは可能ですが、3つの階層を持つストアドプロシージャを使用したくない場合もあります。
+1
ビジネスロジックをストアドプロシージャまたはデータアクセスレイヤーに配置しないでください。私はデータベースをオブジェクトとして見ることが好きです - 格納されているメソッド、データエンティティであるフィールドストアドプロシージャは、データベースへのデータの入出力を可能な限り短時間で行い、複数のレコードの結合に基づいて列を更新するなど、SQLに適したタスクを実装するために使用されます。 –
+0
@ztech、そうですね、何？誰もが嗜好と見解を持っていて、「はずし」はありません。 OPの質問とは何が関係していますか？ – tuinstoel
+2
ポイントは良いデザインの習慣を奨励することです。たとえば、Windows 95のルートディレクトリに512個以上のファイルを置く方法を尋ねる人がいると、私の最初の応答は「悪い考えであるからDo notです」となるでしょう。あなたのアプリにレイヤーを統合しようとするのは、ほとんどの場合、悪い考えです。私は、後で来て、そのようなものを維持しなければならない人になることを望んでいません。業界の悪いデザインを捨てることは、私たちの生活を楽にします。 –
3
FinnNkへの小道具ですが、ティアを分けなければどうなるかの例を挙げておきます。私は何年もの間、出産時にひどく離れたプロジェクトについて働いてきました。すべての3つの層 - より多くの場合、あなたは、個々のJSPページに一括して言いました。私はそれが現時点ではスマートなもののように思える（あなたが始まったばかりのコードを書くほうが速い）が、この怪物は成長し、成長し、誰もリファクタリングに時間をとらなかった。
ここでは、2,000以上のJSPページが作成され、コードが重複して散在しています。スキーマを変更するには、どのページを有効にするか、それぞれのページを個別にテストするための注意深いバックトラッキングが必要です。経営陣の誰も、短期的な利益、長期的な損失を修正するために時間を費やすことは十分に重要だと考えている人はいません。
Do。ない。行く。この。ルート。
階層を分割することで、より優れた、より速く、よりテスト可能な、よりモジュラーなコードにつながります。あなたはそれのために自分自身に感謝し、（もっと重要なことに）あなたの後に来る人々はそれのためにあなたに感謝します。
2
一部のデータベースでは、NoSQLデータベースのCouchDBやRavenDBなどの外部インターフェイスが公開されています。つまり、ブラウザで実行されているJavascriptは中間層なしでデータベースを呼び出すことができます。
例えば参照：http://www.infoq.com/news/2010/06/couchdb
"行儀HTTP/RESTインターフェースと APIクリーンでシンプルな2層 アプリケーション（サーバとしてHTML + JavaScriptの ブラウザで+ソファ+ジャバスクリプト）"
を
Oracleは内部にWebサーバーを持っていますが、外部にもインターフェイスを公開するストアドプロシージャを使用できます。したがって、ブラウザのJavaScriptは、中間層なしでOracleデータベースを呼び出すこともできます。
常にには、データベースからデータを取得するだけの中間層が必要ですか？私はその必要性に疑問を抱く
（TTTは、以前はTuinstoelとして知られている）
+0
ちょうど不思議なことですが、そのような状況でどのようにセキュリティに対処していますか？興味をそそられる。 –
0
あなたは2層から3層に移動駆動することができるいくつかの例： 1 - お使いのシステムには、クライアント（デスクトップ、ウェブ、モバイル、などの異なる種類を持っています） 2 - システムに異種のデータソースがあります（例えば、非DBリソース）
3ご使用のシステムに特定のクライアント/サーバー通信プロトコルが必要です 4-クライアントからデータ層を非表示にしたい5 Youサーバークラスタとロードバランシングによるスケーラビリティの必要性 6-クライアントに透過的なサーバーとサーバーの統合が必要 7 - Yo （DB接続などの）クライアントの数に共有リソースを使用したい 8-クライアントをdbサーバーまたはサーバーグループから切り離すことによってシステム保守を簡素化したい 9 - ビジネスロジックを別の層に配置したい特定のプラットフォームで 10-クライアントとDB間のトラフィックを減らしたい
0
まず、大きな質問です。他の人が指摘しているように、どちらにもメリットがあります。 「懸念の別離は、」3層の主な利点であり、それはいくつかの方法で配当金を支払う：
- セキュリティ：プレゼンテーションからビジネスロジックを分離することで、あなたは、例えば様々な層に、より厳格なポリシーを適用することができますデータやロジックのないプレゼンテーションフォームをプレゼンテーションゾーンに置くことができますので、匿名ユーザーはあなたの「パブリック」コンテンツにアクセスできます。
- メンテナンス性/管理性 - 多くのことがすでにこれについて言われています
- 再利用/災害復旧：pharamcy管理アプリケーションが第三者が処方箋発注に使用できるサービスと同様にUIを公開したい場合。別の層にビジネスロジックを分離することで、あなたはサービス/ロジックを維持することができる独立UI
のいくつかの他のものがありますが、これらはうまくいけば、「私は例どこを探しています*潜在的な利点
のアイデアを与えます私たちは絶対に3つの層を必要とし、例外はありません "* - この業界では、その明確なカットは実際には何もありません。現実には、それぞれの問題にアプローチする何百もの方法があります。それには、それ自体のメリットがあります。人々はこれをやって、特定のアプローチが生まれてから、より多くの問題を経験的に解決するアプローチを生み出しています。これらのアプローチは、業界のガイドライン/パターン/ベストプラクティスになります。どのような状況においても、一方のアプローチは絶対に正しく、別のアプローチは絶対に間違っていると信じるのは誤りです。 – MattDavey