Question

我希望这个问题尚未得到解答，但我甚至不知道该搜索什么。

我有一个MVC项目，我需要从DB返回一个用户列表。很简单。但我只想归还某些用户。再一次，简单的东西。

让我困惑的是，我不知道应该把代码放在哪里。如果我把它放在控制器中，我会在多种方法中使用相同的代码，并分布在多个控制器上。

我目前使用该方法返回dbcontext类中的用户。这有效并且似乎有意义，但我想知道是否有更好的方法来做到这一点？这个课程最终会在一个更大的项目中获得巨大的成就。

我看过使用存储库类，但这似乎只是添加了一个额外的层。我正在使用EF6，而不是进行任何单元测试（还）

下面的代码显示了我的dbcontext类的结构（我已经编辑了实际代码，以保持简洁）。

public class LeadsDB :DbContext
{
    public LeadsDB()
        : base("Leads")
    {
    }

    public DbSet<User> Users { get; set; }

    public IEnumerable<SelectListItem> GetUserList(bool includeBlank = true)
    {
        return UserList;
    }
}

Answer 1

正如他们所说：

计算机科学中的所有问题都可以通过另一层次的间接来解决......除了间接层太多的问题。

因此，根据应用程序的大小和范围，您需要确定多少层间接可以让您达到应用程序可维护性的最佳位置。

如果您的应用程序非常小，请继续直接将这些方法放在您的上下文中。如果它的大小足以让你的DbContext变得不可维护，我就会创建存储库。等等。

在我正在处理的应用程序中，我们只与Entity Framework进行交互以进行与数据相关的操作。我们所有的存储库都返回DTO，这是我们数据模型的抽象。我们的控制器进一步将大多数DTO转换为ViewModel，然后再将它们传递给Views。还有一个＆＃34;经理＆＃34;控制器和存储库之间的层，用于处理业务逻辑和安全检查。我们最终得到了很多层次，但我们发现在解耦视图，演示文稿，业务，安全性和数据模型方面具有价值。

Answer 2

这看起来像一个Entity Framework DBContext;如果是这样，那么将其用作数据层。

可能考虑使用“业务层”抽象模型来为对象执行其他操作。您的数据访问层应该只是：处理数据。

如果您有一个单例类作为业务层，那么您可以使用数据层直接处理数据，然后使用业务层将业务逻辑应用于该数据并将其返回到表示层（无论是网站，窗户等）。

业务逻辑层可能会检查缓存中的数据，如果它不存在，则从数据层中检索它，将其放入缓存并将其返回到表示层。

存储与模型相关的方法的位置

2 个答案: