2014-09-30 47 views
0

我希望这还没有得到回答,但我甚至不知道要搜索什么。在哪里存储与模型相关的方法

我有一个MVC项目,我需要从数据库返回一个用户列表。够简单。但我只想返回某些用户。再次,简单的东西。

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

我目前已经把方法返回到我的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; 
    } 
} 
+0

存储库将是您下一个合乎逻辑的步骤。这层很好。位于业务逻辑和数据库访问代码之间。 – 2014-09-30 22:05:52

+0

IMO你的'LeadsDB'类很好,绝对没有意义在其上添加另一个抽象。 – mxmissile 2014-09-30 22:08:26

+0

@mxmissile,你不知道他的解决方案有多大,所以暗示有*绝对*没有意义添加另一层抽象是狭隘的。没有激进的答案......取决于他在做什么以及他的解决方案将取得多大成功,有不同的方法来实现他想要实现的目标。 – 2014-09-30 22:13:32

回答

0

正如他们所说:

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

因此,根据您的应用程序的大小和范围,您需要确定有多少间隔层可以让您在应用程序的可维护性方面达到最佳状态。

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

在我正在处理的应用程序中,我们只与实体框架进行数据相关操作交互。我们所有的仓库都会返回抽象为我们数据模型的DTO。我们的控制器进一步将大多数DTO转换为ViewModels,然后将它们传递给视图。控制器和存储库之间有一个“管理器”层来处理业务逻辑和安全检查。我们结束了很多层面,但我们发现在解耦视图,演示文稿,业务,安全和数据模型方面有价值。

+1

感谢StriplingWarrior,和其他人回复。这个项目将会相当小,所以我会继续做我正在做的事情。 – Wayne 2014-09-30 22:38:40

0

这看起来像一个实体框架DBContext;如果是这样,那么使用它作为你的数据层。

可能考虑使用“业务层”抽象模型来为对象做更多的事情。你的数据访问层应该做只需即:使用数据。

如果你有一个singleton类作为业务层,那么你可以使用数据层直接处理数据,然后使用业务层将业务逻辑应用到该数据并将其返回给您的演示文稿层(无论是网站,窗体等)

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