2
プレゼンテーション層がサービスのみを使用すると想定される場合、サービスクラスは、プレゼンテーション層が利用できるようにするために、リポジトリによって既に実装されているのと同じメソッドを公開する必要があります。DDDでは、プレゼンテーション層はリポジトリクラスとサービスクラスの両方を使用できますか？
これは間違っています。誰かが私のためにそれを明確にすることはできますか？
A
答えて
3
実際にこのレベルの抽象化が必要ないので、間違っていると思います。
アプリケーションサービスはfacadesです。悪いファサードは、それが解決するよりも複雑さを増すものです。このような何か：それは十分な複雑さを解決するか、あなたが明示的にすべてが、できるだけ多くのクライアントを切り離すために追加の層を通過する場合を除き
public int Increment(int v){ v=v+1;return v;}
- それは無用です。 - はい、それはそれを行う方法です
public ActionResult ViewBlogPost(int id){
//I like to name repositories as collections
var blog=_blogs.Find(id);
blog.IsBeingViewedBy(_currentViewer);
return View(blog);
}
+0
これは、ドメインサービスをすべて一緒に避けることを意味しますか？ – Roman
+0
@Am私はアプリケーションサービスについて話しています。ドメインサービスは異なるものです。しかし、ええ、私はドメインサービスを避けようとしています。なぜなら、ドメインサービスの必要性は、モデルには集約されたルートがないという兆候です。 –
0
「レイヤー純度」を持つために：（MVCパターンが使用されている場合）個人的に、私はちょうどコントローラでこれらの事を固執するだろう
。しかし、多くの冗長コードを簡単に避けることができます。すべての一般的なメソッド（save(..)、update(..)、delete(..)など）を定義するBaseServiceを作成します。他のより複雑なメソッドは、ドメインオブジェクトとのやりとりを必要とする可能性があります。
Btwの場合、DDDではリポジトリ層がドメインオブジェクト内からアクセスされることがあります。私はそれが間違っていると思うが、時にはそうである。それもあなたのケースであれば、それはservice > domain object > repositoryであり、「ショートカット」はありません
何層話していますか？どのようなものを開発する責任がありますか？ –
私はアプリケーション全体を開発しています。あなたにアイデアを与えるために、ブログ投稿の読み込み時にビュー数を増やすUIについて話しましょう。私のリポジトリは私にブログエンティティを与え、私のサービスはカウントを増やします。私のUIがサービスとだけやりとりすることになっているのであれば、そのサービスはメソッドを公開する必要があります。このメソッドは、リポジトリを呼び出してブログを取得します。ですから、サービスの代わりにリポジトリからブログエンティティを直接取得するUIが正しいのでしょうか？ – Roman