MVC设计模式模型逻辑



根据MVC设计模式,如果我们创建一个用户(数据库工作),并且我们必须向用户发送一封带有激活码的邮件,那么在模型创建数据库记录后,这是否适合模型或控制器?

MVC模式用于在业务逻辑(模型)和GUI(视图)之间创建抽象。控制器只是这两个块之间的适配器(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启发的设计模式是两层的组合:

  • 表示层
  • 模型图层

表示层由视图、控制器和(主要在面向web的解决方案中)模板组成。该层处理用户交互。它识别用户输入、生成响应并管理用户界面的其他方面。控制器基于用户交互来更改模型层的状态。

模型层处理域业务规则,并与不同形式的存储交互。模型层和表示层一样,不是任何单一的对象或类,而是一组具有不同职责的结构。

在这种情况下,处理用户管理的服务使用不同的结构是有意义的,这些结构既可以发送验证电子邮件,也可以创建帐户并存储这个新创建的用户。

模型层中的服务就像屏障一样,将表示层与业务逻辑隔离开来。它们处理域对象和存储抽象(数据映射器、存储库、工作单元等)之间的交互

TL;DR

带有新创建用户激活码的电子邮件应该从模型层发送。

控制器是一个简化消息并将消息委托给模型对象的对象。

您将在模型中拥有一个Interface对象(或边界对象),它表示两个系统(系统和电子邮件)之间的链接。类EmailClient。您的模型对象将在需要时与此对象协作。

相关内容

  • 没有找到相关文章

最新更新