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

本文关键字：解决方案 API Web net 项目 OData 基于 | 更新日期: 2023-09-27 17:54:53

到目前为止，在我的办公室里，我已经开发了一些中小型的基于。net的应用程序，我曾经这样构建它们——

  • Web层. Net Web api)
    • <
  • 控制器,过滤器/gh>
  • 服务(包含业务逻辑)
  • iservice
  • Repository(使用实体框架/ADO.Net从数据库获取数据)
  • IRepository
  • ViewModel

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

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

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

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

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

问题4 -我仍然需要一个独立的业务逻辑层(服务层)之间的数据源和控制器，所以我可以保持我的控制器尽可能瘦

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

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

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

  1. Web API控制器

    • 接收Rest请求，对c#对象进行序列化/反序列化

  2. BL (Business Layer)

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

  3. 助手层

    • 在内存处理中将简单的数据实体/Poco转换为复杂的UI/Return实体，最终转换为Json。这一层有大量的对象代码来完成任务。它有相当的逻辑。
  4. 库层
    • 获取简单的数据实体，主要是IEnumerable<T>，使用我们自定义的Micro ORM。有时在特定情况下，我们甚至直接获取DataTable/Dataset并使用它们进行进一步处理
    5. ADO Helper(自定义Micro-ORM)
    • 使用反射在运行时填充POCO，使用DataReader或DataAdapter，这部分可以用任何其他数据获取机制代替

公共实体:(它们可以跨上面定义的层访问，但我们进行了限制以确保一致性)

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

UI -最终结果实体

Input -用于来自REST调用

的输入

Constants—用于整个项目中的硬编码和常量值

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

相关文章：