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

时间：2015-06-10 16:42:11

标签： c# asp.net asp.net-web-api odata

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

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

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

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

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

问题2 - 如何使用Controller中的OData进行查询 - ＆gt;服务 - ＆gt;存储库

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

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

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

1 个答案:

答案 0 :(得分：0)

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

  1. Web API控制器

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

  2. BL（业务层）

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

  3. 辅助层

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

    6. 共同实体:(可以跨上面定义的层访问它们，但我们限制以确保一致性）

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

    UI - 最终结果实体

    输入 - 来自REST调用的输入

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

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

相关问题
最新问题