在ASP中使用接口作为视图模型.. NET MVC是一个不好的实践

Question

我想这个标题很好地概括了我想问的问题。

这里有一个蹩脚的例子我想做的是

public interface IMyObject
{
    string Property1 {get;set;}
    List<string> PropertyList {get;set;}
    string GetOneValue();
}
public class MyObject
{
    public string Property1 {get;set;}
    public List<string> PropertyList {get;set;}
    public string GetOneValue()
    {
        return PropertyList.Find(p=>p.Name=="MyName");
    }
}

public class MyFactory
{
    public IMyObject GetMeMyObject()
    {
        // perform some db query and return interface.. like
        IMyObject obj = null;
        using(context = new dbcontext())
         obj = context.MyObjects.Where(o=>o.Value == "somevalue").FirstOrDefault<IMyObject>();
        return obj;
    }
}

public class MyController : Controller
{
    public ActionResult Index()
    {
        IMyObject objInterface = new MyFactory().GetMeMyObject();
        return View(objInterface);
    }   
}

Index.cshtml
@model MyLib.IMyObject
<h1>@Model.Property1</h1>
<p>@Model.GetOneValue()</p>

这里我使用接口作为cshtml视图的模型。我的问题是，

这是一种不好的做法吗?
1. 我在这里做的有缺点吗?

Answer 1

我的观点是，只有当它对你想要实现的目标有某种价值时，我才会添加它。在大多数情况下，模型对象将是一个简单的POCO，因此您必须考虑是否需要抽象。

我猜一个潜在的好处可能是更灵活的视图，因为你依赖于接口而不是具体的对象。这意味着您可以为接口的不同实现者重用视图。同样，我只会在它增加了价值的时候才这样做。

Answer 2

让我把这个问题"是否有缺点?"转过来:是否有优点?我没看到，至少以你为例没有。

你会为你的视图提供一个模型的替代实现吗?如果没有，就不要使用接口。一般来说，模型应该是非常轻量级的，主要由属性和少量用于改变内部状态的逻辑组成。

接口应该代表你的对象的契约:"这里有一堆东西，我保证这个东西将能够做。"如果你不需要保证，因为只有一个对象可以合理地完成这些事情，那么就不要使用接口。