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>

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

这是一种不好的做法吗？
我在这里做什么有缺点？

提前致谢。

Answer 1

我的两分钱是我只会添加它，如果它为你想要达到的目标增加某种价值。在大多数情况下，模型对象将是一个简单的POCO，因此您必须考虑是否需要抽象。

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

Answer 2

让我回答“有缺点吗？”周围：是否有优势？我没有看到一个，至少不是你的例子。

您是否会为您的视图提供模型的替代实施？如果没有，请不要使用界面。一般来说，模型应该非常轻量级，主要由属性和可能用于改变内部状态的微量逻辑组成。

界面应该代表你的对象的契约：“这里有一堆东西，我保证这件事能够做到。”如果您不需要进行保证，因为只有一个对象可以合理地执行这些操作，请不要使用接口。

使用接口作为ASP.NET MVC中视图的模型是一种不好的做法

2 个答案: