問題タブ [loose-coupling]

Service Oriented Architecture Principlesサイトでは、SOA ではサービス構成が重要であると述べています。しかし、Service Loose Coupling も同様に重要です。

これは、「オーケストレーション層」だけがシステム内のサービスの呼び出しを許可されているということですか?

私が SOA を理解しているように、「オーケストレーション層」はすべてのサービスを 1 つのソフトウェア アプリケーションに「接着」します。それをFig.AとFig.Bに描いてみました。

2 つの違いは、図 A ではアプリケーションがサービスで構成され、すべてのロジックが「オーケストレーション レイヤー」で実行されることです (サービスへのすべての呼び出しは「オーケストレーション レイヤー」からのみ実行されます)。図 B では、アプリケーションはサービスから構成されていますが、1 つのサービスが別のサービスを呼び出します。

図 B のアーキテクチャは、SOA の「サービスの疎結合」原則に違反していますか? サービスはSOAで別のサービスを呼び出すことができますか? さらに一般的に言えば、サービスの疎結合、抽象化、再利用性、自律性などの点で、図 A のアーキテクチャは図 B のアーキテクチャよりも優れていると考えられますか?

私の推測では、A アーキテクチャははるかに普遍的ですが、「オーケストレーション レイヤー」と呼び出されたすべてのサービスとの間で不要なデータ転送が追加される可能性があります。

マイクロコントローラーでプロジェクトに取り組んでおり、いくつかの設定を保持する必要があります。これが iPod だとします。CurrentSongPlaying、 などのさまざまな設定を保存CurrentVolumeして、再度電源を入れたときにそれらの設定を復元できるようにする必要があります。私が遭遇している問題は、すべての不揮発性設定をメモリからシリアル化/逆シリアル化できる単一の構造体に保存することは理にかなっていますが、クラスが実行しないとそれを実現する方法を見つけることができません.サイズ/タイプ情報のために保存する必要がある設定を含むすべてのクラスを含む、不揮発性メモリからのシリアライゼーション/デシリアライゼーション。何を保存しているのかを知らなくても、これらすべての設定をメモリに永続化できる設計パターンはありますか?

私は自分のJSライブラリを構築しています。
ライブラリは、主にブラウザの違いを解消するために役立つ、小さな独立したモジュールと、少し大きいユーティリティで構成する必要があるという考え方です。
乾いたままでいるのか、ゆるく結合しているのかを判断できないため、何かを成し遂げるのに苦労しています。

例？与えられた：

• テンプレートからdom要素を生成する処理を行う小さなライブラリ
• ダックタイピングの問題を処理するもう1つの問題（is_function、is_array ...）
• そして最後にモーダルボックスを作成します。最後のものが必要です：
  • いくつかのタイプチェック
  • テンプレートライブラリの1つの関数のみを使用してモーダルを作成します

モーダルボックスライブラリの私のオプション：

1. 100％乾燥し、他の2つのライブラリに依存します。ただし、モーダルボックスライブラリのみをダウンロードしたいユーザーの場合は、他の2つで作成する必要があります。
2. ユーザーが開始時にオプションのオブジェクトを渡して、必要な機能を指定できるようにします。デフォルトではライブラリの1つになります。これは優れていますが、実際には、90％の場合、同じシグネチャで関数を作成するのは面倒なので、提供されているライブラリを使用することを意味します。さらに、モーダルボックスコードが複雑になります。
3. 100％緩く、モーダルボックスライブラリに必要な機能を再現します。よりターゲットを絞っており、エッジケースをチェックする必要がないため、おそらくより効率的です。ただし、バグは2か所で修正する必要があり、ダウンロードサイズが大きくなります。

ですから、私は2つの極端な状況の間で振動する時間を無駄にし、100万回リファクタリングし、決して満足することはありません。
もっと一般的な質問をしようとしていましたが、サイズとパフォーマンスの問題、および広範な使用法のために、それが本当にJSに関係していることに気付きました。

そのような場合に従うべき既知のパターンはありますか？これについて受け入れられている方法は何ですか？どんな考えでも大歓迎です。

[編集：]
これは私の懸念を詳しく説明していると私が見つけた唯一の記事です。記事が言うように、

DRYは重要ですが、[...]低結合度と高凝集度も重要です。[...]すべての[原則]を考慮に入れ、それぞれの状況でそれらの相対的な価値を比較検討する必要があります

私はこの状況でそれらの価値を比較検討することができないと思います。

次のコードを検討してください。

ここで、それを疎結合するようにリファクタリングしたいと考えています。最終的には次のようになります。

大丈夫そうですよね？これで、どの実装でもインターフェースを使用できるようになり、すべて問題ありません。

実装が WCF クラスであり、リファクタリングが行われる前に using ステートメントが何らかの理由でそこにあったと言ったらどうなるでしょうか。つまり、WCF 接続を閉じます。

したがって、インターフェイスでDisposeメソッド呼び出しを実装するか、ファクトリ インターフェイスを使用して実装を取得し、その周りに using ステートメントを配置する必要があります。

私には (このテーマは初めてですが)、これは漏れやすい抽象化のように思えます。実装が何かを処理する方法のために、コードにメソッド呼び出しを配置する必要があります。

誰かがこれを理解し、私が正しいか間違っているかを確認するのを手伝ってくれませんか.

ありがとう

私は、さまざまな病院（顧客）からのデータを消費し、データベースからの構成の読み取りに基づいて、特定のビジネスルールをそのデータに適用する病院統合システムを設計しています。Javaを使用している場合、私の最初の本能は、さまざまなビジネスルールを表す一連のインターフェイスを構築し、次に具体的なインスタンスを挿入して（Spring / guiceを使用して）完全に構成されたオブジェクトを構成することです。これにより、構成ロジック（Hospital Fooに適用する必要のあるビジネスルール）と実際のビジネスルール自体を明確に分離することができます。

残念ながら、私はJavaを使用しておらず、Luaを使用しています。私は過去数日間、Luaの文献に没頭してきましたが、DIに最も近い類似物はモジュールの使用であるように見えます。さらに、実行時にluaモジュールがどのように解決されるかを管理するルールは、ローカルファイルシステムへの問い合わせに完全に基づいているようです。

「モジュールパターン」は、私が求めているもの（構成ロジックとビジネスロジックの分離）を実現するための最良の/唯一の方法ですか？もしそうなら、Luaのモジュール読み込みルールをどのように活用して、実行時に読み込まれる実際のモジュールを変更できますか？

私が取り組んでいるアプリケーションでは、新しいエンティティがリポジトリに追加されたときにトリガーされるアクションがあります。新しいアクションの 1 つは、サービス (エーテルのどこかにある Web サービスではなく、サービス層など) を使用して、オブジェクトが入ってきたときにいくつかのビジネス ルール操作を実行することになっています。

これはすべてうまくいきますが、使用する必要がある正確なサービスは、操作しているエンティティのプロパティによって異なります (基本的に、エンティティがどの顧客に関連しているかによって異なります)。アクションが呼び出す必要のあるサービスのフレーバーとアクションを疎結合にしたいと考えています。

私が考えているのは、エンティティを受け入れて正しいサービスを返すファクトリを実装することです。ただし、これは少し厄介なようです。これを設定するより良い方法はありますか？

実行時に正しい実装を判断するために IoC コンテナーを使用することを検討しましたが、いくつか (Ninject と Windsor) をざっと調べただけでは、この種の操作に適しているとは思えません。

単位間の変換を行う必要があります。各単位には、名前と整数の 2 つの部分があり、整数部分は正または負のいずれかになります。Unitクラスに依存性注入があり、疎結合である必要があります。たとえば、将来何かを追加する必要がある場合、このクラスを使用している他のクラスを変更する必要はありません。

Convert()私のユニットクラスには、ユニット間で変換するためのメソッドも必要です。私はこれらのリンクを見ました：

• .NET Framework での型変換
• シンプルで効率的なバリュータイプを作るためのパターン

しかし、これらは疎結合のようです。

この問題の推奨設計パターンを教えてください。

best practice特定のケースがあり、それを処理する方法を知りたいです。

特定の .NET フレームワーク (Web アプリケーション) を作成します。この Web アプリケーションは、次の方法によって、他の多くの Web アプリケーションに対するプラットフォームまたはフレームワークのように機能します。

依存する Web アプリケーション (プロジェクト ビジネスのクラス、rdlc レポート) を別のソリューションで作成し、それらをビルドします。

その後、結果の dll への参照をフレームワークに追加します。

そして、一連のユーザー コントロール (依存する Web アプリケーションごとに 1 つ) を作成し、フレームワーク自体のフォルダーに配置します。

それは正常に動作しますが、特定のユーザー コントロールに対する変更、または依存する Web アプリケーションのいずれかに対する変更です。参照を再度追加して、フレームワーク全体を公開する必要があります!!

私がやりたいことは、これらのさまざまな Web アプリケーションとフレームワークを疎結合にすることです。そのため、フレームワークを 1 つだけ公開することができ、ユーザー コントロールまたはさまざまな Web アプリケーションに対する変更は、フレームワーク全体ではなく、更新された部分を公開するだけです。

これを実行できるようにコードをリファクタリングするにはどうすればよいですか?

最も重要なことは次のとおりです。

依存するアプリケーションの変更がこのアプリケーションに属する場合は、フレームワーク全体を公開しないでください。更新された部分を公開するだけです。

いくつかの独立したモジュールを表示するページを持つ MVP で設計された Java アプリケーションがあるとします。特に、アプリには 2 つの独立した MVP モジュールがあり、これを考慮します。アプリには、前述のモジュールが通信する必要がある機能があります。モジュールは、機能専用のインターフェース (API) A および B を提供します。この機能のロジックを処理する Manager (M) もあります。マネージャーは、ページをトラバース (または何らかのコンテキストを使用) して、考慮されている機能に参加する必要があるモジュールへの参照を取得できます。

Manager のコードの以下のスニペットは、私が考えているアプローチを示しています。

1. EventBus を介した非同期イベントの使用

   /li>

2. 直接参照の使用

   /li>

質問は次のとおりです。

オブジェクト間の通常の通信 (条件の確認、値の戻りなど) に EventBus を使用しても問題ありませんか? それとも、実際のイベントにのみイベント パターンを使用する方がよいでしょうか (何かが起こったことをサブスクライバーに通知することを意味します)。2 番目のアプローチに従うことは疎結合に反しますか? 他のパターンの方が適しているのではないでしょうか？

直感的には、2 番目のアプローチの方がクリーンです。

現在、SOAP またはより単純な HTTP REST のようなアプローチを使用して Web API を作成しています。同時に、サーバーとクライアントを多かれ少なかれ独立して進化させる方法が複数あります。これは大きな利点だと思います。

主な欠点の 1 つは、HTTP の使用に伴うオーバーヘッドがあることです。アプリケーションがデータベースに直接アクセスする代わりに、サービス API を使用してデータを公開することを増やす予定です。HTTP を使用するとオーバーヘッドが大きくなり、レイテンシが増加することが懸念されます。もちろん、キャッシングを利用することもできますが、それによって複雑さも増します。

提案の 1 つは、はるかにパフォーマンスが高いはずの WCF NetTcp バインディングを使用することです。このテクノロジーを選択すると、サーバーとクライアントを独立して進化させるという REST の利点が失われるのではないかと心配しています。密結合を犠牲にしてパフォーマンスを向上させると思います。

私の質問は次のとおりです。WCP NetTcp バインディングを使用して、すべてのクライアントを更新することなく API を進化させることは可能ですか? 言い換えれば、このバインディングを使用する場合、クライアントとサーバーの間にどの程度の結合が期待できるでしょうか?