29

ASP.NET MVC プロジェクトを見ると、常に疎結合アーキテクチャが表示されます。

Web アーキテクチャで疎結合が必要なのは何ですか (単体テストを作成しない場合)。

これの長所と短所は何ですか？

レイヤー/クラスを分離する主な理由は何ですか?

たとえば、DAL を変更したくない場合はどうすればよいですか? つまり、いつ DAL 全体を変更する必要があるのでしょうか?! これで、DAL を UI に結合できました。これの何が悪いのですか？

4

13 に答える 13

32

疎結合を使用すると、他の部分に影響を与えることなく、アプリケーションの 1 つの領域に変更を加えることができます。理論的には、ビジネス レイヤーや UI レイヤーを再構築せずに、データ アクセス レイヤーの変更などを行うことができます。

これにより、アプリケーションの柔軟性が向上し、変更に熟達し、保守が容易になります (アプリケーションのある領域の変更が別の領域を破壊することを心配する必要がないため)。

于 2010-05-19T19:17:42.760 に答える
22

自明なほど小さくないプロジェクトでは、多くの時間を節約できます。ここで、自明なほど小さいとは、数千行未満のコード (言語によって異なります) と定義しています。

その理由は、超小規模プロジェクトを乗り越えると、それぞれの変更や更新がより緊密に結合されるほど難しくなるからです。疎結合であるため、前進し続けたり、機能を追加したり、バグを修正したりできます。

ある時点で、どのプログラムも保守、更新、および追加が困難になると思います。設計が疎結合であるほど、その点が遅れます。密結合の場合、おそらく約 10,000 行のコードの後、メンテナンスが不可能になり、いくつかの機能を追加することは、本質的にゼロから書き直さない限り不可能になります。

疎結合であるため、1,000,000 ～ 10,000,000 行のコードに拡張できますが、妥当な時間内に変更を加えて新しい機能を追加することができます。

これらの数字はただでっち上げたものなので文字通りに解釈することを意図したものではありませんが、それがどこで役立つかを理解するためのものです。

プログラムを更新する必要がまったくなく、それがかなり単純な場合は、密結合で問題ありません。そのように始めても問題ありませんが、いつ分離するかを知っていますが、どの時点でそれが有益になるかを知るには、疎結合コードを書いた経験が必要です。

Enterprise Fizzbuzzは、オーバーエンジニアリングで船外に出る可能性があることを意図的にユーモラスに示した例であり、すべてのプロジェクトが同じレベルのデカップリングを必要とするわけではありません。

MVC は、ほとんどのプロジェクトが役立つほど大きくなるため、一般的には出発点として適していると考えられています。プロジェクトが大きくなると、そのレベルのデカップリングでは不十分で、M 部分自体をいくつかのレイヤーに分割する必要があります。すべてに万能というわけではありませんが、MVC はほとんどのプロジェクトにとって適切な分離方法です。

于 2011-06-28T20:14:57.590 に答える
12

紙の上では、疎結合には多くの利点がありますが、実際には、それを正しくするのは難しいです。以下にいくつかの利点を示します。

  • システムは、ライフサイクルの観点から独立して進化できます。

  • システムはさまざまな言語で記述でき、最終的にはさまざまな OS 上で実行できます。

  • システムは、さまざまなチームによって構築できます (構築する必要があります)。システム開発をアウトソーシングできます。実際、これがソフトウェア開発組織を拡張する唯一の方法です。

ただし、いくつかの欠点があります。

  • 最初はより多くの作業が必要であり、うまくやらないと、そのメリットが見られない可能性があります.

  • API/コントラクトの定義は非常に難しく、経験豊富な開発者が必要です。最初は簡単ですが、長期的には難しいです。

  • 疎結合の一般化は、実際にはどこでも緩い型付けにつながる可能性があります。明確に定義された意味のあるオブジェクトを使用する代わりに、すべてのクラスまたはインターフェイスに追加されたジェネリック型の「オブジェクト」パラメーターまたは戻り値の型の使用が増加していることがわかります。これの悪影響は、平均的な開発者が、いわゆる疎結合システムの両側で型を想定して、ワイルド キャスト操作をどこにでも追加する可能性があることです。

  • 一部の疎結合手法は、直接的な依存関係を回避する目的で、インターフェイス定義の一般化に基づいています。インターフェイスは、定義されて公開されると石に刻まれることになっていることを忘れないでください。これは私が疎結合と呼んでいるものではありません。JIT やメソッド オーバーロードなどの手法を利用する .NET クラスは、より優れた疎結合手段になる可能性があります。したがって、これらのインターフェイスとファクトリの問題は、型、アセンブリ、テスト ケースなどの増加につながり、将来的には単純に作業と複雑さが増えることです。物事を単純化する代わりに、1 つのシステムを構築する代わりに、多くのシステムを構築する必要があります。「N層システムはN倍の作業です」:-)

  • 疎結合は、これまでに作成された中で最も強力なツールの 1 つであるコンパイラ (C# など) を何らかの形でバイパスします。そして、それが実際の目的全体ですが、コンパイラーが行っていたすべての基本的な作業 (型チェックなど) を別の場所 (テスト) で行う必要があり、コストがかかるため、いくつかの欠点があります。

  • 多くのすぐに使用できるツールは、おそらく機能しなくなります。Visual Studio の「定義に移動」や「すべての参照を検索」などは使用できません。

于 2011-06-28T21:45:52.817 に答える
8

疎結合アーキテクチャは、アプリケーションを変更または拡張する必要がある場合に役立ちます。また、重要なアプリケーションは、最終的には変更または拡張する必要があります。

疎結合アーキテクチャを使用して設計する場合、要件が変更されたときにアプリケーションの一部のみが影響を受けるはずです。緊密に結合されたアーキテクチャでは、多くの部分を変更する必要があり、影響を受ける部分を正確に特定することは困難です。

私の意見では、TDD の主な利点の 1 つは、疎結合アーキテクチャの促進に役立つことです。

于 2010-05-19T19:20:42.910 に答える
5

「正しい」方法は他の回答で説明されたと思います。しかし、私は今、私自身の経験から書きます。

アーキテクチャを決定する際に考慮しなければならないことがいくつかあります。

a。クライアント

すべてを「正しい」方法（優れたアーキテクチャ、テストなど）にするのに十分な時間がありますか？クライアントが結果をすばやく確認したい場合があります。時間が短く、最高水準の製品にはならないのではないかと不満を言うことができますが、結局それが問題です。この状況では、クライアントに何が得られるかを説明し、私たち全員が知っているスパゲッティコードを記述します。

クライアントの要件は何ですか（信頼性、スケーラビリティ、拡張性、速度の観点から）？これは自明だと思います。クライアントが「正しい」方法を指示する場合があります。私たちはクライアントに「正しい」方法を提供することができますが、最終的にはクライアントが決定します（もちろん時間とお金に応じて）。

システムを開発した後、誰がシステムをサポートしますか？素敵で分離されたコードをサポートしたいと思います。ですから、私がコードを書くとき、私はそれを「正しく」するために最善を尽くしています。いつか、ビューとコントローラーを結合したり、サービスを結合して満足したりすることがあります。私自身のコードを知っていると、それをサポートするのは簡単です。

b。計画

プロジェクトの規模はどのくらいですか？一部のプロジェクトは非常に小さいため、複雑なアーキテクチャは保証されません。

ソフトウェアが将来急速に成長する可能性はありますか（より多くの機能）？これは最大の課題の1つです。しかし、ソフトウェアが成長すれば、それは成功であることを意味します。おそらく、より多くのリソースを使用できるでしょう。コードをリファクタリングして「正しく」するのは比較的簡単です。

プロジェクトにはスケーラビリティの問題が発生する可能性がありますか？ユーザーとデータの観点から、決して成長しないプロジェクトがあります。単純な組み込みデータベースが問題なく機能するのに、OracleRACデータベースのセットアップを使用して真剣に見えようとしているプロジェクトを見てきました。

プロジェクトを開始しましたか、それとも他の開発者から引き継いでいますか？これは、誰がソフトウェアをサポートし、ソフトウェアが成長するかという質問の組み合わせです。他の開発者からスパゲッティコードを入手する可能性があります。それを「正しく」するための時間とリソースはありますか？

c。開発チーム

チームはデカップリングを正しく行うのに十分な経験がありますか？経験が浅いときは、「正しい」コードを書こうとしました。そして私は失敗しました。重要なのは、開発チーム、そのスキルと知識を本当に知ることです。この問題を過小評価しないでください。経験の浅い開発者と仕事をするとき、私は通常、アーキテクチャにいくらかの犠牲を払っています。行われる犠牲は、私が持っている最高の知識に基づいた推測です。アーキテクチャには、犠牲にできる点とできない点があります。通常、以前に行った1つ以上の犠牲が戻ってきて、あなたを噛みます。

開発者は自動テストの作成経験がありますか？自動テストを行うだけでは不十分です。それらは（可能な限り）完全であり、正しく行われる必要があります。テストが弱い場合は、テストをまったく行わない方がよいでしょう。穴だらけの壁にもたれたくないでしょう。

結論：

私たちは皆、プロになりたいと思っています。そして専門家として、私たちはすべてのことを考慮に入れなければなりません。「正しい」方法で物事を行うことに時間とエネルギーを浪費することはできません。時々、私たちは他の要因（現実）を見て、私たちの選択をしなければなりません。そして、最も重要なことはそれと一緒に暮らすことです。

于 2011-07-05T09:04:54.960 に答える
4

利点:

  • スケーラビリティ - データベース アクセス レイヤーを拡張できます
  • 交換可能性 - 例: メール プロバイダー コード
  • 保守性 - コードを 1 か所変更するだけ
  • ユニットテストの設定が簡単 - データベースのようなオブジェクトをモック化できます

短所:

  • おそらくいくつかの余分なコード行
  • 追加のインターフェース クラス
于 2010-05-19T19:38:47.500 に答える
3

まず、単体テストを作成する必要があります;)

基礎となるデータベースを変更する必要が生じたとします。データ アクセス コードがビジネス ロジックと密接に結合している場合、これは膨大な作業になる可能性があります。疎結合のコードでは、ビジネス ロジックは影響を受けません。

バックエンド コンポーネントを活用するコマンド ライン ユーティリティを作成する場合はどうすればよいでしょうか。システムに複数のエントリ ポイントを提供することは、疎結合コードを使用する方がはるかに簡単です。

于 2010-05-19T19:22:25.400 に答える
3

スケーラビリティを提供します。たとえば、背後にサービス層がある場合、それを複数のサーバーに分けることができます。また、依存関係が少なくなり、変更が容易になります。コードのサポートも容易になります。

ここで興味深い小さな記事を見ることができます: SOA - Loosely Coupled...What?

すぐにそれは言います：

疎結合システムは、実行中の他のコンポーネントへの遅延バインディングまたは動的バインディングのサポートを含む多くの利点を提供し、コンポーネントの構造、セキュリティ モデル、プロトコル、およびセマンティクスの違いを仲介できるため、揮発性を抽象化できます...

于 2010-05-19T19:24:01.410 に答える
2

クラスを結合および分離する主な理由は、拡張性のためです。一方の変更が他方に影響を与えるべきではありません。

現在 MYSql データベースを使用してデータを保存しているアプリケーションを構築する場合。ここで、データをバックエンド システムとして MSSQL に格納するという新しい要件があります。MYSQL ライブラリとより統合されたシステムを構築する場合、どのようなソリューションが残されますか。アプリケーション全体を MSSQL 用に書き換えます。MSSQL に基づいて新しい DAL を作成し、システム (UI) を変更せずに DAL をシステムにプラグインします。

アプリケーションはインターフェースに基づいてルーチンを呼び出しており、インターフェースは実装から解放されています。

Unity または MEF について読んでみてください。これらのトピックは、優れた洞察を提供します。

于 2011-07-02T21:19:22.147 に答える
2

ブラウザーベースの HTTP Web UI と通信していなくても、奥にあるものが役立つ可能性があるためです。したがって、その特定の UI から切断できるようにする必要があります。

于 2010-05-19T19:18:35.290 に答える
2

それはすべて、ビジネス上の利益とともにアプリケーションを作成する意図に依存します。ビジネスがそれを拡張することに熱心で、十分な燃料 (コーパスの読み取り) が関与している場合、アーキテクトはアプリケーションが長期的な利益を享受できるように十分に検討できます。

したがって、利点は次のとおりです:-

1) サード パーティのコントロール/コードを使用している場合: 常に「ラッパー/アダプター レイヤー」を記述して、何らかの理由でそれが使用できない場合に、アプリケーション リポジトリ コードを乱すことなく別のものを取得してアダプター レイヤーを変更できるようにします。

2）データベースリクエストを必要とする場合と必要としない場合がある「サービスレイヤー」に特定の複雑な機能をカプセル化する：リクエストとレスポンスが同じままであるため（時間とともに確実に変化する可能性があるため）、常にパフォーマンスに取り組むことができるため、有益です。出力を変更することなく、その特定のコードの。ユニットケースを配置すると、コードのパフォーマンスも測定できます。

3) 特定のロールに特定のコードを書かせる : 多くのロールを作成すると、チームのメンバーは、関係のないコードの山で迷子になるのではなく、特定のリポジトリに集中しやすくなります。

4) 焦点を絞った QA : レイヤード アーキテクチャを使用している場合は、焦点を絞った QA の改善に常に役立ちます。

5) バグの発見/解決: 階層化されたアーキテクチャを使用し、適切なログが整っていると仮定すると、バグを発見して解決する時間を常に節約できます。

欠点は次のとおりです。

1) この種のフレームワークでアプリケーションをセットアップするには、余分な時間がかかります。そのため、「市場投入」が遅れます。

2) テクノロジーに熱中しすぎると、オーバーキルに陥る可能性があります。

3) 追加のトランザクション待ち時間: データがさまざまなレイヤーを通過するため、トランザクションごとに追加される余分な待ち時間があります。

DALの変更について:-

もちろん、機能よりもパフォーマンスが優先されるときがあり、DAL の変更につながるデータ プロバイダーの検討を開始する必要があります。

DAL を UI に結合すると、DAL を変更するたびに (あったとしても、いつでも)、運用環境でバイナリ全体を再リリースする必要があります。これには独自の問題があります（ここで説明することをためらっています。必要に応じて、いつでも含めることができます）

それが理由です。最初は常に時間をかけて、アプリケーションの「自己破壊」がいつ発生するかを結論付けたほうがよいでしょう。私は、アプリケーションの寿命が何であるかを意味していました.これがうまく答えられれば、残りはすべてうまくいきます.

于 2011-07-05T07:15:38.063 に答える
1

分業。これは人間にとって関心の分離に相当します。HTML の第一人者は、SQL 女神とは独立して作業できる必要があります。

フロントエンドへの劇的な変更は、バックエンドを破壊することなく続行できる必要があり、その逆も同様です。つまり、2 人ではなく 1 人を雇うだけでよいということです。

于 2010-05-20T01:05:28.290 に答える
0

誰も議論していない角度で対応します。一時的なデカップリング。いくつかの方法で実行できます。

上記 (async モナドを除く) を使用する場合、メソッド呼び出しではなく、明示的にメッセージを処理することがよくあります。これは、メッセージ パッシングの仕組み (メッセージの処理の冪等性、転送中にメッセージを格納するためのキュー、エンベロープに添付されたセキュリティ データ、リクエスターではなくハンドラーでの再試行ロジックなど) に関連する考え方につながります。

一時的に分離されたメッセージ指向のアーキテクチャに移行することで、アプリケーションの拡張が容易になります。特に、パブリッシュ/サブスクライブを主に行っている場合 (イベント駆動型アーキテクチャも参照)、何でもイベントをリッスンして反応することができます。インテグレーターの実装を最初の呼び出しサイトにバインドしないでください。

作業をキューにプッシュする Web サイトは、IO が発生するのを待ってワーカー スレッドをぶらぶらさせないため、一般的に応答性が高くなります。また、長期的に維持するのに費用がかからないこともよくあります。

さまざまな種類のコンパイル型カップリング (およびその他のメトリック)については、 http: //www.ndepend.com/Metrics.aspx を参照して、自分で読んでください。

于 2011-07-05T17:19:47.490 に答える