.net 3层，没有存储库，有实体框架？

我决定放弃存储库，而是直接在我的服务中使用它们。但是，我现在不确定EF DbContext应该放在哪里，以及SaveChanges（）应该从哪里调用。以下是我目前的设计：

• MVC客户端
  • 视图模型
• 核心BLL
  • 域模型
  • 管理者
  • 服务-用于与第三方和DAL对话
• 数据DAL
  • 实体模型
  • DbContext

服务应该在BLL中，还是应该在DAL中

---

此外，欢迎您对上述内容提出任何改进建议，谢谢

如果您不想使用repository模式，顺便说一句，如果在DAL中正确使用该模式，那么您可以做的最好的事情是：

1-从数据层中删除实体模型。将EF实体视为域模型。DAL将只包含DBContext

2——考虑使用AutoPAPER轻松地将域模型转换为视图模型。转换必须在你的“经理”上完成，我通常称他们为引擎

3-仅将DBContext注入管理器类

---

因此，流程将是MVC->Services（注入管理器）->managers（注入DBContext）->SQLServer。此外，始终考虑跨服务关切操作的服务，例如认证、授权、调用引擎、日志记录和业务规则验证。EF labmda表达式只能在dbcontext可用的manager类中编写。

这里没有完整的设计模式。您采用了MVC三层模式，并说“我不喜欢存储库，所以我要去掉它们”，然后尝试保持结构的其余部分。那不行。我鼓励您看看您试图解决的具体问题，然后看看哪些设计模式最能解决这些问题。事实上，您没有提供足够的信息来提供有用的答案。@Necoras如果我选择不使用存储库，我缺少什么？服务不能与我的dbcontext对话吗？仅此而已？因为服务用于与DAL“对话”，显然，您应该将SaveChanges放在那里，并从经理那里调用相关的服务函数。我还建议您考虑将服务注入核心BLL中，这样您就可以更改实现。我不太清楚您为什么不想使用存储库。您似乎希望将这些服务用作存储库，并将一些附加功能委托给它们。这对于一个小项目来说可能很好，但对于一个更大的项目来说，维护起来会更困难。@djvuk所以如果我要添加存储库，那么我还需要UnitOfWork？我想我最大的担忧是缺少延迟执行，或者为了防止延迟执行，您是否将查询作为存储库中的一个函数，即GetByName（name）。如果是这样的话，那么您在服务中就不会有与调用存储库功能完全相同的功能了吗？这难道不是不必要的抽象吗？@JacobMason如果您关心的只是延迟执行，那么您应该让您的存储库始终返回IQueryables。然后，当您的服务调用.ToList时，实际上会查询数据库。但这也有其自身的缺陷：。实际上，这归结为我最初所说的：您需要查看您想要解决的问题，并根据这些问题选择DAL。只是积垢？构建一个restapi。复杂的命令？查看CQR。