ハードウェア設置用の制御システム（水循環システム）を構築しています。ハードウェア記述層と制御層の2つの層で設計しました。

ハードウェア記述レイヤーには、パイプが熱交換器やその他の機器にどのように接続されているかを記述したハードウェアのマップが含まれています。このレイヤーのデータはインストールごとに構成可能であり、実行時に読み込まれます。したがって、ハードウェア記述層のすべてのクラスは、何らかの方法でシリアル化可能である必要があります（Hibernate / XMLへのシリアル化などを介して）。

コントロールレイヤーは、ハードウェア記述レイヤークラスをインテリジェンスで装飾するため、熱交換器は、たとえば、それに関連付けられたHeatExchangerControllerを取得します。

このシステムでは、制御層のエンティティは、ハードウェア記述を介して最も近いネイバーを探す必要がある場合があるため、熱交換コントローラーは次のようなことを行う可能性があります。

問題は、これにより、下位層（ハードウェア層）がその上位のインテリジェンス（そのコントローラー）を認識できるようになることです。これは、レイヤー間の一方向の依存関係ルールを破るだけでなく、すべてのハードウェア記述クラスをシリアライズ可能にする必要があるため、上位レイヤーへのすべての参照はオプションである必要があり、一時的であると宣言される必要があるため、コードが複雑になります。

このようにHW記述レイヤーを介してコントロールを使用できるようにするのが良いか悪いか、または別の方法があるかどうかを判断しようとすると、少し行き詰まります。私は、HW記述レイヤーのほとんどすべてをミラーリングして委任することを含む、1つの方法しか考えられません。これは、邪魔になる方法のようです。

ですから、私の質問は、この状況を認識し、ヒントや経験を持っている人がいるかどうかです。名前はありますか？そのための良いパターン/ベストプラクティスはありますか？また、この状況を回避して回避した他の有名なライブラリ/フレームワークはありますか？

ありがとうございました。

大学のクラス プロジェクトとして Google App Engine アプリケーションを作成しました。今、私はそれを商業的に使用するために最適化する必要があります.

現在、コードは非常に遅いです。それぞれに多くのプロパティを持ついくつかのモデルしかありません。モデル コードを書き直す前に、モデルの数を増やした場合、つまりデカップリングを増やした場合にアプリケーションが高速になるかどうかを知る必要があります。そして、どの時点までモデルを他のモデルに分割することを検討する必要がありますか?

別の質問として、デカップリングがパフォーマンスにプラスの影響を与える場合、モデル内のプロパティの数は、データストアから取得する時間に正比例しますか?

補助ソースから外部データをロードする必要があるモデルがあります。モデルがデータをフェッチできる（スワップ可能な）Webサービスは多数存在しますが、サービスの変更を困難にするコードを作成したくありません（コストは可変使用量と固定使用量によって大幅に異なり、変更される可能性があります）必要になります）。

インタラクションを実行するためのドライバーを作成したいと思います（サービスの切り替えが必要な場合は、さらにカスタムドライバーを作成します）。残念ながら、ドライバーとモデルは緊密に結合されているため、コードをプラグインまたはgemに抽出することは意味がありません。すべてのコードをモジュールに抽出し（例を参照）、現在、モデルの上でコードを宣言しています。

Rails（3.0.0）には、モデルと緊密に結合されたモジュールを格納するための規則がありますか？これを行うためにプラグインを使用する必要がありますか？これは「app/helpers」ディレクトリに関連付けられていますか？そうでない場合、コードを保存するのに最も適切な場所はどこですか？ありがとう！

ASP.NET MVC 2 プロジェクトがあります。レイヤーを切り離しました。サービス層とリポジトリ層があります。コントローラーはサービス メソッドを呼び出し、サービス レイヤーのみがリポジトリ内のメソッドを呼び出します。

問題は、リポジトリ クラスのメソッドが LINQ 結合を使用していることです。このメソッドから、結合されたテーブルからいくつかのデータをマージした型を返したいと思います。(つまり、Name = a.Name、Position = b.Position) そして、リポジトリ クラスでは常に IEnumerables を返します。したがって、この場合、(名前、位置) の新しい型を定義し、その型をリポジトリ関数から返す必要があるようです。しかし、そのクラスを別の ViewModel クラスに再マップする必要があります。（私は懸念を分離しているので、リポジトリでviewmodelクラスを使用すべきではありませんよね？）これは多くの異なるクラスにつながります。EF クラス、結合テーブルのクラス、ビューモデル クラス。

私は正しい道にいますか？

教えてください。

ありがとうございました

依存性逆転とデカップリングについての理論を読んでいますが、この2つの違いがわかりません。

依存性逆転は、高レベルのコンポーネントが低レベルのコンポーネントに依存しないように、機能コンポーネントを分離することについて話します。

デカップリングは、同じこととそれを達成する方法について話します。しかし、それから私たちは物事をさらに混乱させるIoCコンテナを持っています。独立したコンポーネントの実行時の結合を提供するため、依存性逆転のコンテナーまたはさらに優れた依存性注入コンテナーと呼ばれないのはなぜですか？

次に、制御の反転があります。基本的に依存性逆転の原則と同じですよね？同じことを表す3つの用語があるのはなぜですか？それとも私は盲目ですか？

1. 3つの違いは何ですか？
2. IoCはIoCコンテナで何をする必要がありますか？

私はJavaで書かれたモジュールを1つ持っています.Webサービスモジュールはリクエストを処理し(ここではいくつかのビジネスルール)、データベースに値を保存(変更または削除)し(Hibernateを使用)、ステータスレスポンスを送信します)。そのモジュールをリファクタリングして、最後に 2 つのモジュールが存在するようにすることは合理的ですか? はいの場合、モジュール間の情報交換の推奨事項は何ですか? ありがとう ！

WSDL から生成されたいくつかのクラスがあり、入力データを読み取り、Web サービスを呼び出し、応答を書き込む 2 つの小さなアプリケーションを作成する必要があります。

現在、Web サービス呼び出しによって返されたオブジェクトからデータを取得する非常に単純なラッパー クラスを作成しました。生成された型の代わりに独自のクラスを返すWeb サービス プロキシのラッパーを作成しました。私が目指しているのは、分離されたモデルであり、生成されたクラスを単純なアプリケーションに公開しません。

しかし、私は全体をオーバーエンジニアリングするかもしれないと思います。今のところ、2 つの小さなアプリケーションは、モデル クラスとラッパーとほぼ同じサイズになりますが、後でさらに多くの要件が発生すると確信しており、柔軟に対応したいと考えています。

生成されたクラスを非表示にする必要がありますか (この部分をデータ アクセス レイヤーと考えます)、または最初のバージョンの生成されたクラスを使用する必要がありますか?

注- 元の投稿を一番下に移動しました。これは、このスレッドの新規参入者にとってまだ価値があると思うからです。すぐ下に続くのは、フィードバックに基づいて質問を書き直す試みです。

完全に編集された投稿

わかりました、私は特定の問題についてもう少し詳しく説明しようとします。ドメインロジックとインターフェイス/プレゼンテーションロジックを少しブレンドしていることに気づきましたが、正直なところ、どこで分離するかわかりません。我慢してください:)

私は、（とりわけ）物を移動するための物流シミュレーションを実行するアプリケーションを作成しています。基本的な考え方は、ユーザーが Visual Studio に似たプロジェクトを表示し、ここで概説しようとしているさまざまなオブジェクトを追加、削除、名前付け、整理、注釈付けなどを行うことができるということです。

• 項目と場所は、基本的な動作のないデータ項目です。

  /li>

• WorldStateは、アイテムと場所のペアのコレクションです。WorldState は変更可能です。ユーザーはアイテムを追加および削除したり、場所を変更したりできます。

  /li>

• プランは、希望する時間に別の場所にアイテムを移動することを表します。これらは、プロジェクトにインポートするか、プログラム内で生成できます。WorldState を参照して、さまざまなオブジェクトの初期位置を取得します。プランも変更可能です。

  /li>

• 次に、シミュレーションがプランを実行します。それは多くのかなり複雑な動作やその他のオブジェクトをカプセル化しますが、最終的な結果はSimulationResult です。これは基本的に、このコストと計画がどれだけうまく達成されたかを説明するメトリックのセットです (プロジェクト トライアングルを考えてください)。

  /li>

基本的な考え方は、ユーザーがこれらのオブジェクトを作成し、それらを結び付け、再利用できる可能性があるということです。WorldState は、複数の Plan オブジェクトで使用できます。その後、シミュレーションは複数のプランで実行できます。

恐ろしく冗長になるリスクを冒して、例

問題は、次のようなものが実行されるときです。

したがって、基本的に、ユーザーが呼び出しを介して WorldState (およびおそらくプロジェクト全体) から項目を削除しようとするworld.RemoveItem(item)と、その項目がその WorldState を使用する Plan オブジェクトで参照されないようにする必要があります。もしそうなら、私はユーザーに「おい！次のプランXがこのアイテムを使用している！それを削除しようとする前にそれを処理してください！」と伝えたい. 通話で望ましくない種類の動作は次のとおりです。world.RemoveItem(item)

• アイテムを削除しますが、プランはそれを参照します。
• アイテムを削除するが、Plan にアイテムを参照するリスト内のすべての要素をサイレント モードで削除させる。(実際には、これはおそらく望ましいことですが、二次的なオプションとしてのみ使用できます)。

したがって、私の質問は基本的に、そのような望ましい動作をきれいに分離した方法で実装するにはどうすればよいかということです。これをユーザーインターフェイスの範囲にすることを検討しました（したがって、ユーザーがアイテムで「del」を押すと、プランオブジェクトのスキャンがトリガーされ、world.RemoveItem（item）を呼び出す前にチェックが実行されます）-しかし（a）私はまた、ユーザーがworld.RemoveItem(item)自分自身を呼び出すことができるように、カスタム スクリプトを作成および実行できるようにしています。(b) この動作が純粋に「ユーザー インターフェイス」の問題であるとは確信していません。

ふぅ。まあ、誰かがまだ読んでいるといいのですが...

元の投稿

次のクラスがあるとします。

したがって、宇宙船のサイズがそのホームの MaximumShipSize 以下でなければならないという制約が存在するとします。

では、これにどのように対処すればよいでしょうか。

伝統的に、私は次のように結合された何かをしました:

これは、このような単純な例では扱いやすいものですが (おそらく悪い例です)、制約が大きくなり、より複雑になるにつれて、より関連する機能が必要になることがわかりました (たとえば、メソッドを実装するbool CanChangeMaximumShipSizeTo(double)か、データを収集する追加のメソッドを実装する不要な双方向の関係 (この場合、SpaceBase-Spaceship がほぼ間違いなく適切です) と複雑なコードを書くことになり、所有者側とはほとんど関係がありません。

では、この種のことは通常どのように処理されますか? 私が検討したこと：

1. ComponentModel INotifyPropertyChanging/PropertyChanging パターンに似たイベントを使用することを検討しましたが、EventArgs にはある種の Veto() または Error() 機能があります (winforms でキーを消費したり、フォームの終了を抑制したりできるように)。しかし、これがイベンティングの悪用に該当するかどうかはわかりません。

2. または、明示的に定義されたインターフェースを介して自分でイベントを管理します。

asdf ここにこの行が必要です。そうしないと、フォーマットが機能しません

しかし、これがより良いかどうかはわかりません。また、この方法で自分のイベントをローリングするとパフォーマンスに影響があるかどうか、またはこれが良い/悪い考えである理由が他にあるのかどうかもわかりません。

2. 3 番目の選択肢は、PostSharp または IoC/依存性注入コンテナーを使用する非常に風変わりな aop です。私はまだその道を進む準備ができていません。

3. すべてのチェックなどを管理する神オブジェクト -神オブジェクトのスタックオーバーフローを検索するだけで、これは悪くて間違っているという印象を受けます

私の主な懸念は、これはかなり明白な問題のように思え、かなり一般的な問題だと思っていましたが、それについての議論を見たことがありません (たとえば、System.ComponentModel は PropertyChanging イベントを拒否する機能を提供していません。そうですか?); これは、私が (もう一度) カップリングまたは (さらに悪いことに) 一般的なオブジェクト指向設計のいくつかの基本的な概念を把握できなかったのではないかと心配しています。

コメント? }

これは少し曖昧かもしれませんが、私はUIを更新するいくつかのクラスがあるプログラムに取り組んでいます。基本的にすべてのUIリクエストを（とりわけ）受け取り、それらをUI自体にルーティングする「ミドルマン」クラスを作成しました。これにより、UIクラスはミドルマンとのみ対話します。

問題は、UIクラスのインターフェイスに最大20の異なる関数があり、私の仲介者クラスは基本的に下位レベルのクラスから呼び出しを受け取り、UIで本質的に同じ関数を呼び出すことです。これはどういうわけか全体の目的を打ち負かしています。これはよくある問題だと思います。これを行うためのよりエレガントな方法はありますか？

ありがとう、

午後

OOシステムを可能な限り分離するために、私は次のアプローチを考えています。

1）オブジェクトが相互に登録および検出できるサービスのようなRMI/ディレクトリを実行します。彼らはインターフェースを介してこのサービスと話します

2）オブジェクトがメッセージを公開できるメッセージングサービスを実行し、サブスクリプションコールバックを登録します。繰り返しますが、これはインターフェースを介して行われます

3）オブジェクトAがオブジェクトBのメソッドを呼び出したい場合、上記の＃1を通じてターゲットオブジェクトの一意のIDを検出し、オブジェクトBのメッセージサービスにメッセージを公開します。

4）メッセージサービスはBのコールバックを呼び出してメッセージを送信します

5）Bは要求を処理し、メッセージサービスでAの応答を送信します

6）Aのコールバックが呼び出され、応答を取得します。

このシステムは実際には可能な限り分離されていると思いますが、次の問題があります。

1）通信は通常非同期です

2）したがって、リアルタイムではありません

3）システム全体の効率が低下します。

この設計が明らかに適用できない他の実際的な問題はありますか？このデザイン全般についてどう思いますか？