基于 OData / Web API 的 .Net 项目的解决方案架构

solution architecture for an OData / Web API based .Net project

到目前为止，我已经在我的办公室开发了许多中小型 .Net 基于 Web 的应用程序，我曾经在这些应用程序中构建它们，就像这样 -

我以前在我的解决方案中针对上面列出的每个项目都有不同的项目。

但现在我们正在转向 OData Web API 并试图摆脱 entity framework。所以我对我的解决方案架构应该是什么样子有点困惑。

问题 1 - 我的 DBContext 文件应该放在哪里？

问题 2 - 我如何使用控制器 -> 服务 -> 存储库中的 OData 进行查询

问题 3 - 我是否仍然可以遵循上面给出的架构模型并使用 OData 而不是 entity framework 从数据库获取数据？

问题 4 - 我仍然需要在数据源和控制器之间有一个单独的业务逻辑层（服务层），这样我就可以使我的控制器尽可能薄

如果我问任何 wrong/silly 问题，请原谅，因为这是我第一次尝试弄清楚如何使用 OData 来执行我的任务。

以下是我们在项目中所做工作的详细信息，如果能对您有所帮助的话。我们有 Web API 服务，它有 API 控制器，用于 Json 序列化最终结果。以下是重要的层及其各自的作用：

Web API 控制器
- 接收 Rest 请求，从/到 C# 对象序列化/反序列化
BL（业务层）
- 业务处理和外部服务集成（如 Web 服务）
辅助层
- 在内存处理中将简单的数据实体/Poco 转换为复杂的 UI / Return 实体，最终转换为 Json。这一层有很多 Linq to objects 代码来很好地完成任务。它有相当多的逻辑。
存储库层
- 使用我们的自定义 Micro ORM 获取简单的数据实体，主要是 IEnumerable<T>。有时针对特定情况，我们甚至直接获取 DataTable / Dataset 并使用它们进行进一步处理
ADO 助手（自定义微型 ORM）
- 在运行时使用Reflection填充一个POCO，使用DataReader或者DataAdapter，这部分可以替换成任何其他dtaa fetch机制

公共实体：（它们可以跨上面定义的层访问，尽管我们限制以确保一致性）

数据 - 简单的 POCO 类，填充数据库数据

UI - 最终结果实体

输入 - 用于来自 REST 调用的输入

常量 - 用于整个项目的硬编码和常量值

Web API 下的所有 C# 层都可以创建为 dll，因为关系是单向的，从 BL - Helper - Repository - ADO Helper。始终可以插入或调整用于特定目的的任何附加层。区分每个实体的具体角色很重要。