ASP.NET MVC 数据访问层

Posted 2023-02-24

【中文标题】ASP.NET MVC 数据访问层

【英文标题】：ASP.NET MVC Data Access Layer

【发布时间】：2013-06-21 21:53:54

【问题描述】：

我正在开发一个 ASP.NET MVC 项目。在我的解决方案中，我有以下项目： BlogApp.Web（ASP.NET MVC 应用程序）， BlogApp.Data（类库）

我想知道如何实现数据访问层。我想使用 EntityFramework Code First 方法。我在考虑存储库模式，但这真的有必要吗？我读过它只是 ORM 之上的下一层，这并不是真正需要的。所以不要像这样写方法：

GetAllPosts(Tag t) 
    db.Posts.Where(p => p.Tags.Contains(t)).Skip(x).Take(y).Select(p => p);

我在控制器中创建数据库上下文并编写相同的查询？我不需要在我的模型周围实现分页和编写包装器。

【问题讨论】：

参考DRY原则：不要重复自己。在短期内，设置可能需要更长的时间（与大量复制和粘贴相比没有那么长），但从长远来看，它将为您节省大量的维护和测试时间，因此调试 - 我们都知道这可能需要更长的时间首先编写代码。

【参考方案1】：

不确定这个问题是否属于这里。

无论如何，如果你在控制器中编写数据访问逻辑，而另一个控制器中需要相同的逻辑，你会怎么做？将其复制粘贴到新控制器中？那不好。任何时候，你在复制和粘贴时都需要后退一步，这里肯定有问题（也就是代码异味）。

将逻辑分离到不同的层将使您的代码更易于维护和测试。相信我！

【参考方案2】：

您可能听说过存储库模式，它在某些阵营中已经失宠——例如，请参阅Jimmy Bogard's blog。这并不意味着查询应该直接在控制器中编写，除非您的应用程序非常非常简单。

如前所述，您的查询应该只写在一个您的控制器可以使用的地方 - 这可以在存储库方法或专用查询对象中，两者都提供更好的抽象并避免重复。

简单地说 - 您的应用程序是否打算有多个前端，这需要为您的数据访问层单独组装？如果不是，您可能需要考虑合并两个程序集并仅使用命名空间来保持井井有条。