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

Question

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

• Web 层（.Net Web API）
• 控制器、过滤器
• 服务（包含业务逻辑）
• IService
• 存储库（使用实体框架/ADO.Net 从数据库中获取数据）
• IRepository
• 视图模型
• 型号

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

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

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

问题 2 - 我将如何使用来自 Controller -> Service -> Repository 的 OData 进行查询

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

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

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

Answer 1

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

1. Web API 控制器

   • 接收 Rest 请求，Serialize / De-Serialize from / To C# objects

2. BL（业务层）

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

3. 辅助层

   • 在内存处理中将简单的数据实体/Poco 转换为复杂的 UI/返回实体，最终转换为 Json。这一层有很多 Linq to objects 代码可以很好地完成任务。它有相当多的逻辑。
4. 存储库层
   • 使用我们自定义的 Micro ORM 获取简单的数据实体，主要是 IEnumerable<T>。有时对于特定情况，我们甚至直接获取 DataTable / Dataset 并使用它们进行进一步处理
5. ADO 助手（自定义微 ORM）
   • 在运行时使用 Reflection 填充 POCO，使用 DataReader 或 DataAdapter，这部分可以替换为任何其他 dtaa 获取机制

Common Entities：（它们可以跨上述定义的层访问，但我们限制以确保一致性）

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

UI - 最终结果实体

输入 - 来自 REST 调用的输入

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

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