問題タブ [loose-coupling]

自己記述型/自動記述型のサービスは、SOA アーキテクチャの優れた点だと考えています。これは、(ほとんど) サービスを呼び出すために知っていることはすべてサービス コントラクト (WSDL など) に含まれているためです。

私にとって自己記述的ではないサービスのサンプルは、Facebook クエリ言語 (FQL http://wiki.developers.facebook.com/index.php/FQL )、または 1 つの文字列パラメーターで XML フローを交換して解析する Web サービスです。 XML と処理の実行。

技術的には、呼び出し元に技術的な影響を与えることなく実装を切り替えることができ、実装/バージョン間の互換性をビジネスレベルで処理できるため、最後のものはさらに技術的に分離されているように見えます。一方、強力なインターフェイスがない (サービスとそのバージョンに希薄化されている) と、サービスが既存の実装に密接に結合されます (サービスを交換し、完全な互換性を確保することがより困難になります)。

この質問は、SOA アーキテクチャで疎結合を実装する方法に関連しています

では、自己記述/自動記述サービスは、SOA アーキテクチャーで疎結合または密結合ですか? ESB に関する影響は何ですか?

任意のポインタをいただければ幸いです。

疎結合コンポーネントをサポートするために Web フォームでイベントを使用する方法を置き換えることができる ASP.Net MVC の機能はどれですか?

たとえば、Web フォームの単純なページャー コントロールを考えてみましょう。

1. ページ番号をクリック
2. ページャーは、新しいページ番号で「PageChange」イベントを発生させます
3. このサブスクライブしているページ/コントロールはイベントを受け取り、新しいデータを取得してバインドするための呼び出しの開始を処理します。

同様にサポートする ASP.Net MVC で使用できるツール

• 疎結合
• コンポーネントの再利用性
• 単一のページ/ビュー (非常に複雑な「ポータル」タイプのページなど) のロジックの分離。

階層化された Web アプリケーションを開発しています。仕様:

• 3層、データ層、ビジネス層、UI層。
• C# でプログラミング
• データレイヤーはエンティティ フレームワークを使用します

IEnumerable<T>現在、linq 2 エンティティを介してデータ レイヤーをビジネス レイヤーに返すことを計画しており、ビジネス レイヤーはデータを UI レイヤーに返します。

ui レイヤーはデータ レイヤーの存在を認識していないため、T がデータ レイヤーで定義されている BLL から渡された IEnumerable の結果をどのように処理しますか?

これを行う方法に関する良い例はありますか。私はファクトリ/インターフェース/レイヤーを疎結合するための抽象化に非常に慣れていないことに注意してください。

ntier アプリケーションでデータを渡すという質問をここで見ました。エンティティ レイヤーをすべてのレイヤーで共有することをお勧めしますが、他のレイヤーがデータベースにクエリを実行できるようにしたくありません。

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

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

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

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

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

3 つのオブジェクト A、B、C
があるとします。B は次のインターフェイスの実装です。

インターフェイスでイベントを発生させる 2 つの関数を B に追加します。

A はホスティング クラスであり、指定されたイベントを発生させるために B の関数を呼び出します。CI でインターフェイス B またはクラス C をリッスンできることを願っています。B のイベントが発生するたびに、C が通知を受け取り、C がイベントに反応できるようになります。

この仕組みをC#やJavaで実装する方法を考えています。
どんな助けやヒントも大歓迎です!

複数のプロジェクトで機能するアプリケーションをコーディングしようとしています。アプリ内で行うようにインポートを行うときに、常にプロジェクトの名前を指定する必要があるという問題に直面しています。import some_project_name.models この結合を克服して、複数のプロジェクトでアプリを使用できるようにするにはどうすればよいですか?

疎結合コードの実際の利点を理解するのに苦労しています。他のさまざまなオブジェクトと連携できる柔軟なものを作成するために、なぜこれほど多くの労力を費やすのでしょうか? 何を達成する必要があるかがわかっている場合は、その目的のために特別にコーディングしてみませんか?

私にとって、これは型指定されていない変数を作成することに似ています。非常に柔軟になりますが、予期しない値が渡される可能性があるため、問題が発生する可能性があります。また、何が渡されているかを明示的に知らないため、読みにくくなります。 .

それでも、強く型付けすることは奨励されているように感じますが、疎結合は悪いです。

編集:疎結合の私の解釈がずれているか、他の人が間違った方法で読んでいると感じています。私にとっての強い結合は、クラスが別のクラスの具体的なインスタンスを参照するときです。疎結合とは、別のクラスが実装できるインターフェイスをクラスが参照する場合です。

私の質問は、クラスの具体的なインスタンス/定義を具体的に呼び出さないのはなぜですか? これは、必要な変数の型を具体的に定義することに例えられます。私は依存性注入についていくつか読んでいますが、疎結合がより良い設計であることを事実として理解しているようです。

私は現在、プレイヤーが異なる部屋の間を移動したり、アイテムを手に取って使用したり、食べ物を食べたりできる、シンプルなコンソールベースのゲームを作成しています。ゲームの現在の状態では、それについてです。

私が助けを必要としているのは：

私のゲームに適した「イベント」クラスを作成します。私がそれを機能させたいのは、すべてのアイテムと部屋をイベントに関連付けることができるようにすることです。

私はこれに慣れていないので、この種の手順に関連する読み物、または以下の点を考慮してクラスを設定するのに最適な方法、または単にこの種を攻撃する方法についての提案をいただければ幸いです。問題の（クラスの設定方法を決定するのに問題がある）。

さまざまな種類のイベントを作成できるようにしたいと思います。たとえば、次のようになります。

• テキストを出力してから、プレーヤーに質問します。プレイヤーが正解した場合は、何かをしてください。

• テキストを出力し、プレーヤーのインベントリからアイテムを削除してから、プレーヤーを別の部屋に移動します。

私が避けようとしていること：

• ゲームの全体的なポイントは、優れたクラスデザインを実践することです。したがって、責任駆動設計、凝集度、結合度などが重要な側面です。したがって、私はそれが可能な限り単純で、再利用可能で、独立していることを望んでいます。

• アイテムまたはルームがEventクラスの特定のメソッドを呼び出すだけになるように、すべてのイベントをハードコーディングする必要があります。

私が今考えていること：

たとえば、次を使用して新しいイベントを作成（および関連付ける）できるように、いくつかのサブクラスを作成します。itemObject.setEvent（new Event（new Question（ "introText"、 "outroText"、 "correctAnswer"）））;

さらに情報が必要な場合はお知らせください。ありがとう！

イントロコード：

サンプルコードでは、2つの別々のエンティティ（インターフェイス/クラス/その他）を記述しようとしています。これらのエンティティは、一方では（少なくとも）緩く結合されている必要がありますが、他方では相互に依存しており、特定の知識が必要です。お互いの。

上記のシナリオでは、実際にそれらを動作するシステムに統合する3番目のクラスが必要になります。今のところ、上記の定義は可能な限り緩く結合されているため、醜いです。student.register（c）はstudentオブジェクトのみを変更し、course.register（s）はコースオブジェクトのみを変更します。したがって、統合クラスはs.register（c）とc.register（s）の両方を実行する必要があります。

ただし、すべてのregister（）ロジックを1つのクラスに再ログインすると、それらを緊密に結合します。

これを設計するためのよりクリーンな方法はありますか？

現在、Unity で Prism を使用して WPF アプリケーションに取り組んでいます。モデルの機能は、いくつかのクラス ライブラリ プロジェクトに分割されています。懸念事項のグループごとに、1 つの実装プロジェクトと、インターフェイスと列挙型のみで構成される 1 つのプロジェクトがあります。目標は、アプリケーション内の他のものに影響を与えたり、変更したりすることなく、実装 dll を変更または完全に置き換えることができるようにすることです。これが事実であるため、トップレベルのアプリケーションで両方へのハードリファレンスを使用せずに、インターフェイスを実装に登録する方法に少し固執しています。

どこかで一緒に参照する必要があることはわかっていますが、ブートストラップ内の最上位アプリでそれを行うのはベスト プラクティスに反しますか? この特定の問題については、Unity ではなく MEF を調べる必要がありますか?