21

ちょうど今、この質問を入力したところ、興味深いスレッドが表示されました。私はそれが私の質問に答えるとは思わない。

私は貧血モデルを持つことが望ましい.NET MVC3で多くの作業をしてきました。ビュー モデルと編集モデルは、コントローラーからビューに渡すだけのダム データ コンテナーとして最適です。あらゆる種類のアプリケーション フローはコントローラーから来る必要があり、ビューは UI の問題を処理します。MVC では、モデルに動作は必要ありません。

ただし、コントローラーにもビジネスロジックは必要ありません。大規模なアプリケーションの場合は、ドメイン コードをモデル、ビュー、およびコントローラー (および一般的な HTTP) から分離して独立させるのが最善です。そのため、何よりもまずドメイン モデル (DDD に従って集合体に構成されるエンティティと値オブジェクトを含む) を提供する別のプロジェクトがあります。

私は貧弱なモデルから離れてドメインコードのより豊かなモデルに移行しようと何度か試みましたが、あきらめることを考えています. データと動作の両方を含むエンティティ クラスが SRP に違反しているように思えます。

たとえば、電子メールを作成する、Web での非常に一般的なシナリオを考えてみましょう。何らかのイベントが発生した場合、EmailTemplate、EmailAddress、およびカスタム値を指定して EmailMessage オブジェクトを作成するのはドメインの役割です。テンプレートはプロパティを持つエンティティとして存在し、カスタム値はユーザーによる入力として提供されます。また、引数のために、EmailMessage の FROM アドレスを外部サービス (IConfigurationManager.DefaultFromMailAddress) から提供できるとしましょう。これらの要件を考えると、豊富なドメイン モデルにより、EmailTemplate に EmailMessage を構成する責任を与えることができるように思われます。

public class EmailTemplate
{
    public EmailMessage ComposeMessageTo(EmailAddress to, 
        IDictionary<string, string> customValues, IConfigurationManager config)
    {
        var emailMessage = new EmailMessage(); // internal constructor
                                            // extension method
        emailMessage.Body = this.BodyFormat.ApplyCustomValues(customValues);
        emailMessage.From = this.From ?? config.DefaultFromMailAddress;
        // bla bla bla
        return emailMessage;
    }
}

これは、リッチ ドメイン モデルに対する私の試みの 1 つです。ただし、このメソッドを追加した後は、エンティティ データ プロパティを含めてメッセージを作成するのは EmailTemplate の役割でした。それは約 15 行の長さで、EmailTemplate の本当の意味からクラスの注意をそらすように見えました。つまり、EmailTemplate は単にデータ (件名の形式、本文の形式、添付ファイル、オプションの差出人/返信先アドレス) を格納することです。 ）。

私は最終的に、このメソッドを、前の引数が与えられた場合に EmailMessage を作成することだけを担当する専用クラスにリファクタリングしました。実際、貧血ドメインを好むようになってきました。責任を分離し、クラスと単体テストをより短く、より簡潔に、より集中的にするのに役立つからです。エンティティやその他のデータ オブジェクトを「動作のない」ものにすることは、責任を分離するのに適しているようです。それとも私はここで軌道に乗っていませんか？

4

2 に答える 2

0

まあ、それはあなたがそれをどのように見たいかによって異なります。

もう 1 つの方法は、「単一責任の原則はリッチ ドメイン モデルに違反する可能性があるか?」です。

どちらもガイドラインです。ソフトウェア設計のどこにも「原則」はありません。しかし、良いデザインと悪いデザインがあります。これらの概念は両方とも、優れた設計を実現するためにさまざまな方法で使用できます。

于 2016-07-26T08:14:46.590 に答える