数据访问层的架构

Question

我需要帮助使用Entity Framework构建数据访问层。以下是要求：

• 数据库是预先存在的，绝对混乱，它的结构是不可改变的
• 将使用实体框架
• 数据库将被许多.NET MVC应用程序使用，每个应用程序都有自己的业务对象，逻辑和读/写权限。
• 这些应用程序所需的数据对象通常与存储在数据库中的表几乎没有相似之处。
• 对于使用它的开发人员来说，数据访问层需要尽可能简单易用。

我之前从未参与此范围的任何工作，并希望获得有关如何构建此解决方案的任何帮助。到目前为止我所拥有的是：

项目1：DataLayer

•包含纯EF生成的数据模型

项目2：BusinessLayer

•包含将DataLayer中的对象转换为视图使用的业务对象的逻辑，反之亦然。大多数（但不是全部）逻辑在应用程序之间共享。 •包含所有或多个应用程序使用的常见DTO /业务对象

项目3：ServiceLayer.Application1

•包含应用程序1的所有DTO /业务对象 •包含应用程序1

使用的存储库

项目4：ServiceLayer.Application2

•包含Application 2的所有DTO /业务对象 •包含应用程序2使用的存储库

说一个MVC应用程序使用数据层来获取IQueryable，而业务对象FacultyFormattedForAView由来自6个不同表的数据组成，其中一些业务逻辑被抛到顶部。以下是我设想的事情：

1. 应用程序在服务层中创建各自存储库的实例，并调用IQueryable GetAllFacultyFormattedForAView（）。
2. 服务层调用业务层：IQueryable GetAllFaculty（）。 Faculty业务对象由来自4个不同表的数据组成。
3. 业务层回放LINQ语句，将生成的数据层中生成的EF类的对象转换为Faculty
4. 服务层将Faculty对象转换为FacultyFormattedForAView对象并将结果返回给UI

使用此结构，业务层中将存在通用的命令调色板，以避免任何代码重复，并且存储库仅显示特定应用程序可访问的命令，并提供特定于该应用程序的其他格式。

我使用IQueryable而不是IEnumerable，因此可以使用分页和排序。看到我只是将业务对象/ DTO暴露给开发人员，我认为这是好的，但我想要它，如果他们不必为了实际执行查询而做ToList（）或任何事情。

这是我能想到的最好的，但我无法摆脱这样做的感觉。

我会很感激任何反馈。

谢谢。