問題タブ [coupling]

バックグラウンド

私のソリューションは2つのプロジェクトで構成されています。

1. 標準のWindowsアプリケーション
2. アプリケーションが直接使用せず、代わりにターゲットプロセスに挿入するDLL

基本的に、私のアプリケーションの観点から、DLLが満たさなければならない唯一の要件は、私のアプリケーションの作業ディレクトリに存在することです。つまり、DLLは、アプリケーションに関係のある関数をエクスポートしません。

質問

これら2つのバイナリを強力に結合したいと思います。アプリケーションを手動で呼び出す以外に、どのようなオプションがありLoadLibraryますか？

あいまいすぎる場合はお知らせください。

編集

誰も「答えていない」ように見えるので、私はEFraim提案されたことをすることになりました（コメントを参照）。

DLLからダミー関数をエクスポートし、DLLで生成さ*.libれたファイルを、アプリケーションのリンカープロパティシートに追加の依存関係として追加しました。これで、実行時にDLLが見つからない場合、Windowsは適切なエラーメッセージを表示して実行を終了します。追加のボーナスとして、IATの初期化が成功すると、DLLイメージもロックされます。これにより、ユーザーの削除などが防止されます。

私は最近PureMVCフレームワークを学びましたが、プロキシオブジェクトとメディエーターオブジェクト間の結合について少し混乱しています。このページのリンクは、フレームワークを説明するいくつかのドキュメントに接続しています。（前述のページのリンクはPDFを開いていることに注意してください。）

私が調べたPureMVCの図と例は、メディエーターとプロキシの間の直接結合を示していることがよくあります。プロキシの状態が更新されると、新しい通知を送信するのではなく、メディエーター（ファサードからプロキシへの参照を取得する）の状態が更新されます。

これは確かにコードのロジックを単純化するように見えますが、2つの一見異なるコンポーネントを直接結合することにもなります。私の理解では、メディエーターの目的は、ビューからのイベントをPureMVC通知に変換することです。プロキシは、データを収集してビューに中継するための何らかの機能を実行することを目的としています。これらの2つのコンポーネントは、アプリケーションの異なるレイヤーに存在するように見えます。おそらく、必ずしも一緒に結合する必要はありません。

プロキシオブジェクトが状態を更新したときに独自の通知を送信し、ファサードによって関心のあるメディエーターに転送されるようにする方が理にかなっていますか？

これがだまされている場合は許してください。しかし、この正確な質問に当てはまるものは見つかりませんでした。

私は非常に緊密に結合されたレガシーアプリケーションを使用しています。外部サービスからその機能を取得するため、主要な機能の一部を引き出しています。

現在使用されていないコードの削除を開始するための最良の方法は何ですか？極端なベースから始めて、スタックを削除してリファクタリングする必要がありますか？昼食時に、レガシーコードを効果的に使用する方法を見ていきます。

NDC で Bob Martin のエピソードを見終わったところです。彼は、ページの上部にある C# の "using" ディレクティブは、コンポーネント間で作成/暗示される密結合のために悪いと言っていました。

プロジェクト参照と using ステートメントを追加せずに、外部の .dll を使用するにはどのような方法がありますか?

V6 では、ProgId の文字列でオブジェクトを作成できたのを覚えています。それが私が探している手法かどうかはわかりませんが、プロジェクト参照を使用する必要のない言語の例です。 dll.

編集:これは会議へのリンクです。申し訳ありませんが、プレゼンテーションの正確な引用または議事録はありません。記憶によるものです。

私のプロジェクト (ASP.NET MVC を使用) には、AuthenticationService と ProfileService の 2 つのクラスがあります。新しいユーザーが私のサイトに登録すると、認証コントローラーの Register アクションが IAuthenticationService の Register メソッドを呼び出します。これにより、インターフェイスが参照している (コントローラーのコンストラクターに挿入された) 具体的な認証モジュールに従って、ユーザーの認証レコードが作成されます。登録プロセスの一部として、ユーザーのプロファイル レコードが作成されます。これは、挿入された IProfileService で CreateProfile(User) を呼び出すことによって作成されます。

現時点では、コントローラーは両方のサービスを呼び出していますが、コントローラーが実行するビジネス ロジックをできるだけ少なくするというアイデアが気に入っています。認証サービスにプロファイル サービスについて知らせる以外に、他のオプションがあるかどうか疑問に思っています。これには、IAuthenticationService の将来の実装で、CreateProfile を呼び出すことを知る必要がありますか? コードの匂いが随所に書かれていると感じずにはいられません。

もう 1 つの可能性は、{I​​,}RegistrationService という 3 番目のサービスにロジックを任せることです。

この状況を処理するための推奨または推奨される方法は何ですか? ありがとう

罪のない人を保護するために、クラス名が変更されました。

ISomeInterface という名前のインターフェイスがあるとします。インターフェイスを継承するクラス FirstClass と SecondClass もあります。FirstClass は、破棄する必要のあるリソースを使用します。SecondClass はそうではありません。

問題は、IDisposable からどこを継承する必要があるかということです。次のオプションはどちらも理想的とは言えません。

1) FirstClass に IDisposable を継承させます。次に、ISomeInterfaces を扱うコードは、それらを破棄するかどうかを知る必要があります。これは私には密結合のようなにおいがします。

2) ISomeInterface に IDisposable を継承させます。次に、それを継承するすべてのクラスは、破棄するものがない場合でも、IDisposable を実装する必要があります。Dispose メソッドは、コメント以外は基本的に空白です。

＃2は私にとって正しい選択のように思えますが、代替案があるかどうか疑問に思っています.

別のライブラリに依存するインターフェイスを定義するライブラリを作成するのは悪い習慣ですか?

密結合が良くないことはわかっていますが、.NET クラスを使用する場合にもこれは当てはまりますか?

たとえば、.NET では、Color オブジェクトを返すライブラリがある場合、そのライブラリを使用するものはすべて System.Drawing に依存することになります。ライブラリ内に独自の Color 型クラスを作成したほうがよいでしょうか?

モデルは別のモデルに依存できますか? 他のモデルがアクセスしたいログモデルがあるとします。

いくつかのユーザーコントロールがあり、各ユーザーコントロールがタブ項目内、ウィンドウ内にあるとします。

たとえば、これが食品収集アプリケーションであるとしましょう。次に、果物、野菜、スナックのタブがあります。各タブには、その主題の食品のリストが表示され、ユーザーは各セクションで食品を追加、削除、変更できます。食品は個別のテキストファイル、つまり Fruit.txt、Vegetable.txt、Snack.txt に保存されます。

実際のテキスト ファイルは次のようになります (vegetable.txt)。

これは大きなリストであり、すべての野菜をリストに引き出す load メソッドがあります。

私が持っている質問は、この loadVegetables メソッドがコード ビハインド ファイルにあるということです。ReviewAllFood、AddVegetable などの別の画面と、フルーツとスナック。

これは設計上の問題です。このコードを繰り返さないようにどのように設定したのか疑問に思っています。load メソッドがある場所に、VegetableManager (または何か) クラスを配置することもできますが、これは実際にはコードの繰り返しが少ないことを意味するのでしょうか? 次に、各画面で、VegetableManager のオブジェクトを作成し、とにかくその load メソッドを呼び出す必要があります。したがって、効率に関してはそれほど良くないと思いますが、より良い設計を実現しています。

ここで何かが足りないと思います。結束と結合を研究してからしばらく経ちましたが、現在、これらの概念について混乱していると思います。誰かがこの状況の設計を提案し、なぜそれを選んだのか、そしてなぜ私が現在行っている方法よりも優れているのかを説明していただければ幸いです.

読んでくれてありがとう。

n 層アーキテクチャでは、オブジェクト リレーショナル マッピング (OR/M) コードを配置するのに最適な場所は、データ アクセス層です。たとえば、データベースのクエリと更新を NHibernate などのツールに委任できます。

それでも、NHibernate へのすべての参照をデータ アクセス レイヤー内に保持し、その下または上のレイヤーから依存関係を抽象化しておきたいと思います。そうすれば、別の OR/M ツール (Entity Framework など) または何らかのアプローチ (プレーンなバニラ ストアド プロシージャ呼び出し、モック オブジェクトなど) をスワップまたはプラグインすることができ、コンパイル時エラーやアプリケーション全体の大規模なオーバーホールを引き起こすことはありません。テスト容易性は追加のボーナスです。

OR/M を疎結合にして 1 つのレイヤーに含めるラッパー (つまり、インターフェイスまたは基本クラス) またはアプローチを提案してもらえますか? または、役立つリソースを教えてください。

ありがとう。