暴言に入る前に、私の意見を一言で言うと、どこかですべてが一緒にならなければならない...そしてそこを川が流れている.
私はコーディングに悩まされています。
=======
貧血データモデルと私...まあ、私たちはたくさん仲良くしています。ビジネス ロジックがほとんど組み込まれていない小規模から中規模のアプリケーションの性質によるものかもしれません。多分私は少し遅れています。
ただし、ここに私の2セントがあります：
エンティティ内のコードを取り出して、インターフェイスに結び付けることができませんでしたか?
public class Object1
{
public string Property1 { get; set; }
public string Property2 { get; set; }
private IAction1 action1;
public Object1(IAction1 action1)
{
this.action1 = action1;
}
public void DoAction1()
{
action1.Do(Property1);
}
}
public interface IAction1
{
void Do(string input1);
}
これは何らかの形で SRP の原則に違反していますか?
さらに、コードを消費する以外に互いに結び付けられていない多数のクラスを配置することは、実際には SRP のより大きな違反であり、レイヤーを押し上げているのではないでしょうか?
Object1 に関連する何かを行う方法を理解しようとしているクライアント コードを書いている人を想像してみてください。彼があなたのモデルを操作する必要がある場合、彼は Object1、データ バッグ、およびそれぞれが 1 つの責任を持つ一連の「サービス」を操作します。それらすべてが適切に相互作用することを確認するのは彼の仕事です。そのため、彼のコードはトランザクション スクリプトになり、そのスクリプト自体に、その特定のトランザクション (または作業単位) を適切に完了するために必要なすべての責任が含まれます。
さらに、「いや、彼がする必要があるのは、サービス層にアクセスすることだけです。それは Object1Service.DoActionX(Object1) のようなものです。簡単なことです」と言うことができます。では、ロジックはどこにあるのでしょうか。その1つの方法ですべてですか？あなたはまだコードをプッシュしているだけで、何があっても、データとロジックが分離されてしまいます。
したがって、このシナリオでは、特定の Object1Service をクライアント コードに公開し、DoActionX() を基本的にドメイン モデルの別のフックにしないでください。これにより、次のことを意味します。
public class Object1Service
{
private Object1Repository repository;
public Object1Service(Object1Repository repository)
{
this.repository = repository;
}
// Tie in your Unit of Work Aspect'ing stuff or whatever if need be
public void DoAction1(Object1DTO object1DTO)
{
Object1 object1 = repository.GetById(object1DTO.Id);
object1.DoAction1();
repository.Save(object1);
}
}
Object1 から Action1 の実際のコードを取り出しましたが、すべての集中的な目的のために貧血でない Object1 を用意します。
アトミックにして独自のクラスに分けたい 2 つ (またはそれ以上) の異なる操作を表すために Action1 が必要だとします。アトミック操作ごとにインターフェイスを作成し、DoAction1 内に接続するだけです。
それが私がこの状況にアプローチする方法です。しかし、繰り返しになりますが、私は SRP が何であるかをよく知りません。