返回类型为 IEnumerable 而不仅仅是 List？

Question

我正在做一个 .NET MVC 教程。话虽如此，我遇到了这样的代码：

public class MoviesController : Controller
{
    public ActionResult Index()
    {
        var movies = GetMovies();

        return View(movies);
    }

    private IEnumerable<Movie> GetMovies()
    {
        return new List<Movie>
        {
            new Movie {Id = 1, Name = "Shrek"},
            new Movie {Id = 2, Name = "LotR"}
        };
    }
}

电影的索引视图如下所示：

@model IEnumerable<VideoStore.Models.Movie>

@{
    ViewBag.Title = "Index";
    Layout = "~/Views/Shared/_Layout.cshtml";
}

<h2>Movies</h2>
<table class="table table-bordered table-hover">
    <thead>
        <tr>
            <th>Movie</th>
        </tr>
    </thead>
    <tbody>
        @foreach (var movie in Model)
        {
            <tr>
                <td>@movie.Name</td>
            </tr>
        }
    </tbody>
</table>

所以我的问题是，为什么在私有方法GetMovies() 中的MoviesController 中，使用了IEnumerable 返回类型？为什么不使用List 返回类型？

Answer 1

返回类型为 IEnumerable 而不仅仅是 List？

//controller

var a = new Dictionary<string, string>();
return View(a);

var b = new List<string>();
return View(b);

var c = new LinkedList<string>();
return View(c);

// All work with:

@model IEnumerable<string>

虽然使用IEnumerable<> 更开放 sOlid Principles，但我很少建议将任何集合类型接口/类传递给视图。

虽然在 C# 数组/集合中是 First-Class Citizens，但问题是它们在维护 Single Responsibility Principle 时不可扩展。

例如：

// Controller Returns:
var people = .... as IEnumerable<Person>;
return View(people);

@model IEnumerable<Person>

现在假设要向视图添加与组无关的任何信息（如页面标题）.. 你是怎么做的？您可以扩展并创建自己的派生自 IEnumerable<T> 的类，但这会破坏 SRP，因为页面的标题与人群无关。相反，您应该创建一个代表视图所需的一切的一流模型：

public class MyViewModel
{
  public string Title { get; set;}
  public IEnumerable<Person> People { get; set;}
}

return View(myViewModel);

@model MyViewModel

我建议总是这样做。一旦你开始在 MVC 中使用部分或模板，或者想要回发相同的对象，离开IEnumerable<> 变得越来越困难，因为你需要更改部分和/或模板和/或 Javascript...

所以我的问题是，为什么在私有方法GetMovies()中的MoviesController中，使用了IEnumerable<>返回类型？

一般来说Program against an Interface and not an Implementation，也称为Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming,。

这是一个soLid Principle 特别是 Liskov 替换原则。摘录：

可替换性是面向对象编程中的一个原则，它指出，在计算机程序中，如果 S 是 T 的子类型，则类型 T 的对象可以替换为类型 S 的对象（即类型 T 的对象可以是替换为子类型 S) 的任何对象，而不改变程序的任何所需属性（正确性、执行的任务等）。更正式地说，Liskov 替换原则 (LSP) 是子类型关系的特定定义，称为（强）行为子类型，最初由 Barbara Liskov 在 1987 年的会议主题演讲中引入，标题为“数据抽象和层次结构”。它是一种语义关系，而不仅仅是句法关系，因为它旨在保证层次结构中类型的语义互操作性，尤其是对象类型。 Barbara Liskov 和 Jeannette Wing 在 1994 年的一篇论文中简明扼要地描述了该原理如下...

实际上是指当前代码：

    public ActionResult Index()
    {
        var movies = GetMovies();

        return View(movies);
    }

    private IEnumerable<Movie> GetMovies()
    {
        return new List<Movie>
        {
            new Movie {Id = 1, Name = "Shrek"},
            new Movie {Id = 2, Name = "LotR"}
        };
    }

可以改为：

public class MoviesController : Controller
{
    private readonly IMovieDb _movieDb;
    // Dependency Injecting access to movies
    public MoviesController(IMovieDb movieDb)
    {
        _movieDb = movieDb;
    }

    public ActionResult Index()
    {
        var movies = _movieDb .GetMovies();

        return View(movies);
    }
    // ....


public interface IMovieDb
{
    IEnumerable<Movie> GetMovies();
}

现在我们不知道如何检索电影......只要合约/接口满足我们的数据需求，我们就不应该关心。

Answer 2

IEnumerable<> 是与迭代 List<> 相关的接口。返回List<> 将立即向GetMovies() 的使用者公开更多操作，而不是严格必要的操作——例如从集合中添加或删除——这可能更容易引入错误。选择IEnumerable<> 而不是List<> 没有技术上的理由，因为在引擎盖下它的行为是相同的。这个决定纯粹是实际的。

Answer 3

使用 IEnumerable 会削弱耦合，这使得它可以在实现发生变化时与其他具体类型向前兼容。可以在不改变界面的情况下进行以下所有更改：

//Original
private IEnumerable<Movie> GetMovies()
{
    return new List<Movie>
    {
        new Movie {Id = 1, Name = "Shrek"},
        new Movie {Id = 2, Name = "LotR"}
    };
}

//Using an array
private IEnumerable<Movie> GetMovies()
{
    return new Movie[]
    {
        new Movie {Id = 1, Name = "Shrek"},
        new Movie {Id = 2, Name = "LotR"}
    };
}

//From EF
private IEnumerable<Movie> GetMovies()
{
    return dbContext.Movies.Where( m => Name == "Shrek" || Name == "Lotr );
}


//Covariant
class NerdMovie : Movie {}

private IEnumerable<Movie> GetMovies()
{
    return new List<NerdMovie>
    {
        new NerdMovie {Id = 1, Name = "Shrek"},
        new NerdMovie {Id = 2, Name = "LotR"}
    };
}


//Custom type
class MovieList : List<Movie> { }

private IEnumerable<Movie> GetMovies()
{
    return new MovieList
    {
        new Movie {Id = 1, Name = "Shrek"},
        new Movie {Id = 2, Name = "LotR"}
    };
}

//Using yield
private IEnumerable<Movie> GetMovies()
{
    yield return new Movie {Id = 1, Name = "Shrek"};
    yield return new Movie {Id = 2, Name = "LotR"};
}

Answer 4

我无法说出特定代码背后的开发人员的确切推理，但通常我们使用最通用的可接受类型（通常是接口）进行输入，就像在视图中所做的那样。这使我们能够从不同的资源中获取数据并在它们之间进行切换。

至于返回输出，返回泛型接口而不是实际类型没有任何好处，除非函数根据某些条件返回不同的子类型，而您的示例中并非如此。或者，如果类本身正在实现一个接口，那么接口返回最通用的可接受类型是很有用的，原因与上述相同。这也不是你的情况，所以在你的情况下，返回 IEnumerable 没有任何好处。

Answer 5

IEnumerable 是接口所以它更灵活，如果你使用 List ，你会强制接收方法期待 List。