C# 基于OData/Web API的.Net项目的解决方案体系结构

到目前为止，在我的办公室里，我已经开发了许多基于.Net的中小型应用程序，我曾经在这些应用程序中设计过类似这样的应用程序-

• Web层（.Net Web API）
• 控制器、过滤器
• 服务（包含业务逻辑）
• 伊瑟维奇
• 存储库（使用实体框架/ADO.Net从数据库获取数据）
• 间接的
• 视图模型
• 模型

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

但现在我们正转向ODataWebAPI，并试图摆脱实体框架。所以我对我的解决方案架构应该是什么样子有点困惑

问题1-我的DBContext文件应该位于哪里

问题2-如何从Controller->Service->Repository使用OData进行查询

问题3-我是否仍然可以遵循上面给出的体系结构模型，使用OData而不是实体框架从数据库获取数据

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

---

如果我问了任何错误/愚蠢的问题，请原谅，因为这是我第一次尝试找出如何使用OData执行任务。

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

Web API控制器

• 接收Rest请求，从/到C#对象序列化/反序列化

BL（业务层）

• 业务处理和外部服务集成（如Web服务）

辅助层

• 将简单数据实体/Poco转换为复杂UI/返回实体的内存处理，最终转换为Json。这一层有很多Linq到对象代码来很好地完成任务。它有相当多的逻辑

存储库层

• 使用我们的定制Micro-ORM获取简单的数据实体，主要是

  IEnumerable

  。有时，对于特定的情况，我们甚至直接获取DataTable/Dataset并使用它们进行进一步处理

ADO助手（自定义微ORM）

• 使用反射在运行时填充POCO，使用DataReader或DataAdapter，这部分可以替换为任何其他dtaa获取机制

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

数据-简单的POCO类，用于填充db数据

UI-最终结果实体

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

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

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