Asp.net mvc 我应该放置哪个层.edmx和生成的POCO类？

这是关于EF DB First模型的分层设计

到目前为止，我还没有使用过实体框架，只使用了实体，并将其放置在具有Domain/DTO子文件夹的不同项目中。在DataAccessLayer、Business Layer和MVC应用程序中也提到了这一点，并用常用的ADO.Net查询和我的实体的POCO编写了代码。没有问题

现在，我们正在使用Entity Framework DB First模型开发一个应用程序。我们选择DB First模型，因为DB设计不在我们的控制范围内。这是由DBA完成的

我想在这里重复使用旧的简单设计。但不确定我应该在哪里/哪一层精确地适合edmx文件和生成的POCO类。我没有发现任何使用DBFirst方法的分层架构样式的示例

我提到了这个。但他们使用氨丁酸

以下是旧设计的概要

欢迎对设计/样品提出任何建议

编辑：

从下面的答案来看，我认为实体框架产生了POCO，我们可以将现有实体/域层重命名为域层，并将生成的POCO类放在那里。此外，我们还可以简单地将.edmx保存在DataAccessLayer中，其中包含为TDD包装EF的IRepository类列表。这有意义吗？还有什么有价值的观点吗？

更新：

目前我删除了DataAccessLayer，只保留实体层 有一个model.edmx文件和EF生成的类，以及所有 实现IRepository的存储库类。我把这件事提出来 业务层，也包括MVC。我做得对吗？我觉得我在做什么 糟糕的设计：（请建议/帮助）

---

在我看来，使用实体框架正确地否定了对单独DAL的需要。我认为EF是我的DAL。它允许您更加专注于业务部分。EF为您提供所有数据访问代码。您只需在业务层中使用EF上下文即可。对我来说，这是EF的最大好处之一；这就是您的DAL

根据层的分隔方式（程序集中的不同程序集或不同文件夹）取决于您将POCO类放置在何处。如果不同的程序集（这对于大多数项目来说是多余的）然后，所有其他人引用的“公共”程序集是放置POCO类的位置。如果文件夹不同，则名为“Models”或“DomainModels”的文件夹是放置POCO类的位置

特别是对于MVC应用程序，我会将我的POCO类放在“Models”文件夹中（我还有一个“ViewModels”文件夹），将我的.Edmx放在BLL文件夹中，我有时称之为“Logic”

如果您需要一个松散耦合的体系结构来进行测试，那么一个名为Repositories的文件夹，其EF上下文包装在您自己的存储库模式中是一个不错的选择。

编辑：

简短的回答是数据访问层（DAL）

您需要企业架构，并且它会根据您的需要进行更改，但在您的情况下，模型驱动设计模式是一个坚实的解决方案。 您可以使用MVC，也可以从Poco或其他实体（如NHibernet等）驱动您的模型

---

关于代码优先或数据库优先没有任何重要的，仅在架构创建阶段就很有趣。

因为您不幸地受到了首先创建数据库的决定的严重阻碍，您需要使用per

这是一个很好的解决方案，可以解决当你遇到一个糟糕的接口，你必须对其进行编码时该怎么做-在DB周围创建一个按照你希望的方式运行的接口。不要将任何EF类直接暴露给任何东西，除了反腐败层本身

下面是一个阅读示例：

public class SomeReadService : ISomeReadService {
  public SomeViewModel Load(Guid id) {
    using (var dbContext = new DbContext()) {
      // Query the DB model, then *map* the EF classes to SomeVieWModel.
      // This way you are not exposing the shitty DB model to the outside world.
    }
  }
}

public class SomeRepository : ISomeRepository {
  public SomeDomainObject Load(Guid id) {
    using (var dbContext = new DbContext()) {
      // Map the EF classes to your domain object.  Same idea as before.
    }
  }
}

下面是一个写作示例：

public class SomeReadService : ISomeReadService {
  public SomeViewModel Load(Guid id) {
    using (var dbContext = new DbContext()) {
      // Query the DB model, then *map* the EF classes to SomeVieWModel.
      // This way you are not exposing the shitty DB model to the outside world.
    }
  }
}

public class SomeRepository : ISomeRepository {
  public SomeDomainObject Load(Guid id) {
    using (var dbContext = new DbContext()) {
      // Map the EF classes to your domain object.  Same idea as before.
    }
  }
}

---

我仍然会尝试向客户证明，拥有一个单独的团队设计DB将是一场灾难（我的经验强烈表明，这将是一场灾难）。查看是否有某种方法可以向客户提供反馈，向客户证明如果设计DB会更好。

请查看下面类似问题的SO链接：

---

希望这有帮助！！

这张图片没用：它没有显示层之间是如何相互引用的。如果我们不向EF添加任何包装器，我们如何单独测试它？我需要一个松散耦合的体系结构和高度可测试性。在您的repo模式中包装上下文，并将其放在一个名为repositories的文件夹中，bll所在的位置。是这样吗？就DDD而言ned，“EF使用正确”IMO代码是第一位的，而不是数据库是第一位的，而且它并不否定对单独DAL的需要，恰恰相反-它使您能够在域层和DAL之间有一个明确的分离。不知道持久性的好处是：您可以将域dll带到其他地方重用，而无需拖拽特定于EF的内容，您可以在中测试您的层隔离、更少的耦合意味着更好的可维护性，等等。我没有一个答案能够满足DB第一先决条件，并且仍然与DDD兼容（它们是对立的IMO）-我只是对你的断言做出了反应。听起来不错。你能提供一些使用DBFirst方法进行设计的示例代码/模板吗？客户不同意在我们这一方进行DB设计控制。他们要求我们跟踪DBA人员：（.目前，我删除了DataAccessLayer，只保留具有model.edmx文件和EF生成的类的实体。我也将其引用到业务层MVC中。我是否遵循了正确的方法？我将IRepository实现类保留到实体层本身中。我觉得我做的设计很糟糕：（请建议我仍然建议你脚踏实地，干脆拒绝按照这些条款来做这个项目。如果你想在这个行业取得成功，有一些项目如果不太可能成功，你需要放弃