現在のプロジェクトでは、循環依存の問題が発生しています。ビジネスロジックアセンブリは、SharedLibraryアセンブリのクラスと静的メソッドを使用しています。SharedLibraryには、SQLリーダークラス、列挙子、グローバル変数、エラー処理、ロギング、検証など、多数のヘルパー関数が含まれています。
SharedLibraryはBusinessオブジェクトにアクセスする必要がありますが、BusinessオブジェクトはSharedLibraryにアクセスする必要があります。古い開発者は、共有ライブラリ内のビジネスオブジェクトの機能を複製することで、この明らかなコードの臭いを解決しました（非常に反DRY）。私はこれを解決するための私のオプションについて読み込もうとして1日を費やしましたが、行き止まりになっています。
私はアーキテクチャの再設計のアイデアを受け入れていますが、それは最後の手段としてのみです。では、ビジネスオブジェクトが共有ヘルパーライブラリにアクセスしたまま、ビジネスオブジェクトにアクセスできる共有ヘルパーライブラリを作成するにはどうすればよいですか？
値オブジェクト (ロジックなし) とインターフェース用にのみ別のプロジェクトを作成できます。
共有ライブラリ クラスにインターフェイスを実装させ、ビジネス ライブラリはインターフェイスに依存します (ここで、よりテスト可能で分離されたコードを聞くことができますか?共有ライブラリから依存関係を削除することは言うまでもありません) 。
理想的には、共有ライブラリーが依存するビジネス・オブジェクトもこの追加プロジェクトに依存することができます。ビジネス オブジェクトが複雑すぎる場合は、それらをインターフェイスに変換することもできます。
両方のプロジェクトが互いに依存するのではなく、「ダミー」オブジェクト (ロジックなし) のみを持つ別のプロジェクトにのみ依存します。
ビジネス ---> インターフェイスと値オブジェクト <--- 共有ライブラリ
現在、それらは分離されています =)
「共有」ライブラリがあるときはいつでも、ビジネス エンティティ プロジェクトを絶対に参照してはなりません。そうすることで、明らかにわかるように、この問題が発生します。
これに対する解決策は、ビジネス エンティティに依存するすべてのコードを共有ライブラリから削除し、そのヘルパー コードの必要性を再構築するか、そのヘルパー コードをビジネス エンティティ プロジェクト自体の内部に配置することです。
1つの解決策は、間にファサードパターンを配置することです。ここでは、共有ライブラリからビジネスオブジェクトへの直接アクセス/依存関係を回避します。代わりに、libとBOの間のファサードとして機能するレイヤーを使用します。このようにして、共有ライブラリをクリーンで分離してパックできます。