0

Orchard 以外のアプリケーションでは、パターンは、ドメイン/ビジネス ロジック ライブラリ、Web アプリケーション プロジェクト、Web サービス プロジェクトなどによって参照されるプロジェクト内のデータ モデル (およびデータ アクセス コード) を分離することです。

Orchard のアイデアは、他のモジュールのデータ モデルとの関係を意図せずに、データ モデルを 1 つのモジュールだけに制限しているように見えます。

「制限」は、おそらく少し厳しいか、不正確です。おそらく、「制限」は、ここでの言葉遣いとしてより適切な選択です。2 つのモジュール A と B が与えられ、モジュール A の作業中にモジュール B への参照を追加し、そこからエンティティのリポジトリを使用できます。しかし、モジュール B に取り組んでいて、モジュール A からのデータにアクセスする必要が生じた場合、少なくともフレームワーク内でエレガントにアクセスすることはできません。循環参照の問題はここにあります。

この状況では、私はいくつかのアプローチに傾倒しています：

  1. 2 つのモジュールを 1 つに統合します (そして、潜在的に面倒で危険なデータ移行に対処する必要があります)。
  2. フレームワークやリポジトリを使用せずに直接データにアクセスする手段に頼る
  3. 他のすべてのカスタム モジュールによって参照される単一のモジュールにすべてのデータ モデルを配置します (ここでも、データ移行のリスクが高くなります)。
  4. ここで手を挙げて…

モジュールとデータ関係に対する Orchard ソフトウェア設計者の意図を正しく解釈しているものはありますか?

4

1 に答える 1

1

アーキテクチャの観点から、2 つのモジュール間の循環依存が必要な場合、それは通常、それが単一のモジュールであることを意味します。

同様のシナリオで私が頻繁に行うことの 1 つは、実装を共有する代わりに、抽象的な定義とインターフェイスを共有することです。データ モデルを定義するインターフェイスのみを含むモジュール (または単なる通常のアセンブリ) を作成できます。次に、モデルを実装するモジュールとモデルに依存するモジュールの間でこのライブラリを共有できます。唯一の制限は、具体的な実装ではなく、インターフェイスを介してモデルにアクセスする必要があることです。

たとえばITitleAspect、Orchard コアで がどのように実装されているかを確認してください。モデルに同様のインターフェイスを実装し、それらを別のアセンブリで共有できます。これは、コンテンツ パーツとコンテンツ アイテムで非常にうまく機能します。

于 2015-09-24T16:24:17.017 に答える