ドメインレイヤー+リポジトリレイヤーasp.net mvc質問

Question

私のドメインレイヤー/ドメインサービスについて簡単に質問します...このレイヤーにデータベースへの読み取り専用アクセスを許可する必要がありますか？すなわち、IReadOnlySessionをフックアップし、リポジトリ層がCRUDすなわち永続性にアクセスすることのみを許可するかどうかを決定する。または、リポジトリレイヤは、サービスレイヤを持つReadOnlyとCRUDの両方でリポジトリレイヤを呼び出す必要がありますか？

私がむしろ奇妙なことは、サービス層がRepoへの直接呼び出しを行うことが多いことです。そのため、質問はReadOnlyをドメインサービスレイヤーに移動します。

EDIT：

私は（私がやっていることに興味がある人のために）、第一層は、WebUIのです（私は全部で3を持っています私のアプリでは3つの層を持っていることを決定した、ビジネスすべてのビジネスルール、妥当性検査、ユーザーがアクションxを実行できるかどうかのチェック、ユーザーが有効なユーザー、データのレポを呼び出すなどのドメインサービスです。最後の層はリポジトリ層、つまり自分自身のデータベースと会話する層、LinqToSqlを使用しています。すべてのCRUDとReadOnlyロジックはここにあります。私はModelと呼ばれる別のプロジェクトを作成しました。これは実際のLinqToSqlモデルのエンティティです。つまり、Product、Item、Shop、Customerなどです。この非常にプロジェクトはUI、ドメインサービス、リポジトリによって参照されています。うまくいけば複雑です。

Answer 1

アプリケーションでは、1つの「レイヤー」だけがデータベースと通信する必要があります。

リポジトリパターンでは、リポジトリです。

CRUDでもReadOnlyでも問題はありません。リポジトリを経由してデータベースにアクセスする必要があります。

Answer 2

これらのレイヤーの責任は何かを議論しています。リポジトリは、dbに対して抽象化を提供することは明らかです。正しく実行され、リポジトリのユーザは、永続性のためにSQLサーバ、mysql、またはファイルを使用しているかどうかを判断できません。このレイヤーにはすべての必要なクラッシュ操作が必要です。

サービスレイヤは別の抽象化です。永続性のためにリポジトリに依存することがあります。通常はもう少しビジネスロジックがあります。たぶんリポジトリの問題や別のストリームのデータ（gpsなど）。

サービスによってはサービスレイヤーが必要ないものもあります。必要になるまで追加しないでください。サービスレイヤが必要な場合は、それをレポの周りの薄いラッパーにすることで、読み書きを公開することでモデルに1つの直接の依存関係しか持たないようにすることができます。