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

Question

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

• Web 层(.Net Web API)
• Controller 、过滤器
• 服务(包含业务逻辑)
• I服务
• 存储库(使用 Entity Framework /ADO.Net 从数据库中获取数据)
• IRepository
• View 模型
• 模型

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

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

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

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

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

问题 4 - 我仍然需要在数据源和 Controller 之间有一个单独的业务逻辑层(服务层)，以便让我的 Controller 尽可能薄

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

Answer 1

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

1. Web API Controller

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

2. BL(业务层)

   • 业务处理和外部服务集成(如 Web 服务)

3. 辅助层

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

通用实体:(它们可以跨上面定义的层访问，尽管我们限制以确保一致性)

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

UI - 最终结果实体

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

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

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