MVC 設計パターンによると、ユーザーを作成し (データベース作業)、アクティブ化コードを含むメールをユーザーに送信する必要がある場合、モデルがデータベース レコードを作成した後、これはモデルまたはコントローラーに適合しますか?
3 に答える
MVC パターンは、ビジネス ロジック (モデル) と GUI (ビュー) の間の抽象化を作成するために使用されます。コントローラーは、これら 2 つのブロック間の単なるアダプター (Google アダプター パターン) です。
したがって、コントローラーには、コントローラーから必要な情報を取得して採用するために使用されるコードのみが含まれている必要があります。その他のロジックはモデルに含める必要があります。
モデルが単一のクラスではなく、すべてのビジネス ロジックであることを理解している場合にのみ、これは意味があります。
例(実装固有ですが、ご理解いただければ幸いです):
public class UserController : Controller
{
// notice that it's a view model and not a model
public ActionResult Register(RegisterViewModel model)
{
UserService service;
User user = service.Register(model.UserName);
return View("Created");
}
}
// this class is located in the "model"
public class UserService
{
public User Register(string userName)
{
// another class in the "model"
var repository = new UserRepository();
var user = repository.Create(userName);
// just another "model" class
var emailService = new EmailService();
emailService.SendActivationEmail(user.Email);
return user;
}
}
MVC および MVC にインスパイアされたデザイン パターンは、次の 2 つのレイヤーの組み合わせです。
- プレゼンテーション層
- モデルレイヤー
プレゼンテーション レイヤーは、ビュー、コントローラー、および(主に Web 指向のソリューションで)テンプレートから構成されます。このレイヤーは、ユーザー インタラクションを扱います。ユーザー入力を認識し、応答を生成し、ユーザー インターフェイスの他の側面を管理します。コントローラーは、ユーザーの操作に基づいて、モデル レイヤーの状態を変更します。
モデル層は、ドメインのビジネス ルールを扱い、さまざまな形式のストレージとやり取りします。モデル層は、プレゼンテーション層と同様に、単一のオブジェクトやクラスではなく、さまざまな責任を持つ構造のグループです。
この場合、ユーザー管理を扱うサービスが、確認メールの送信、アカウントの作成、およびこの新しく作成されたユーザーの保存の両方を行うさまざまな構造を使用することは理にかなっています。
モデル レイヤーのサービスは、プレゼンテーション レイヤーをビジネス ロジックから分離する障壁のように機能します。これらは、ドメイン オブジェクトとストレージの抽象化 (データ マッパー、リポジトリ、作業単位など) の間の相互作用を扱います。
TL;DR
新しく作成されたユーザーのアクティベーション コードを含む電子メールは、モデル レイヤーから送信する必要があります。
コントローラは、メッセージを単純化してモデルオブジェクトに委任するオブジェクトです。
必要なのは、2つのシステム(システムと電子メール)間のリンクを表すモデル内のインターフェイスオブジェクト(または境界オブジェクト)です。クラスEmailClient。モデルオブジェクトは、必要に応じてこのオブジェクトと連携します。