为MVC中的数据模型创建接口

本文关键字：创建 接口 数据模型 MVC | 更新日期: 2023-09-27 17:50:48

我有一个MVC项目，将通过HTTP 'Post'动词接受数据。我热衷于遵循最佳实践，并想问一个关于如何最好地设置我的模型的快速问题。

通常在处理发布的数据时，我会设计我的控制器来使用具体模型。然而，当我想使用IoC时，我想确定我是否应该像以前那样继续下去，或者我是否应该创建接口。

我的直觉是，我应该在我的web应用程序中使用所有模型和类的接口来有效地实现IoC。我只是想证明我走在正确的道路上!: o)

的例子:

My concrete model
public class PhoneBook : IPhoneBook
{
   public string Firstname {get; set;}
   public string LastName {get; set;}
   public string PhoneNumber {get; set;}
}

My interface
public interface IPhoneBook 
{
   string Firstname {get;set;}
   string Lastname {get;set;}
   string Phonenumber {get;set;}
}
My controller
//Accept posted data from web form
public void Post(IPhoneBook passInDetails)
{
   ... 
}

为MVC中的数据模型创建接口

控制反转(IoC)和依赖注入(DI)并不意味着你需要为所有的模型和类使用接口。

对于"视图"模型，具体类是可以的，因为

  1. 它们是控制器的输入(也可能是视图的输出)
  2. 它们是有效的dto
  3. 它们应该简单且具有独立的目的
  4. 具有数据注释属性的模型验证在定义它们的类型上工作，因此它们应该在模型绑定中使用的具体类型上工作。

所以，我会像你一样继续使用"视图"模型的简单类。另一方面，您的域/核心/业务层模型(MVC中的M)将与您正在建模的域一样简单或复杂。

考虑到IoC工作(当开发MVC应用程序时)是一种简化的方式:

  • 依赖管理
    • 单元测试

这就是为什么以某种方式注入所有依赖是一个好主意(通常通过注入到构造函数中)。当你处理控制器的动作时，你想把你的模型作为参数传递，因为它不影响整个控制器的内部状态。

更重要的是，初始化和管理一些特定于操作的依赖关系并不是控制器的责任。

它更多的模型(或在特定情况下被称为视图模型)更像dto，仅用作代理的形式，方便将数据从一个类映射到另一个类。

根据控制器和模型测试-通常你想测试控制器的行为(在这种情况下传递一些新的模型实例不是问题-你可以用任何可能的数据组合初始化它)或模型本身(但说实话-当它包含几乎没有逻辑，它几乎不是一个测试用例)

  • 你不能在API控制器中使用Interface作为模型。. net框架无法反序列化接口。
  • 带有接口类型参数的方法可以使用由继承同一接口的类创建的对象。

如果我说错了请指正

相关文章：