背景

组织管理管理准备使用Blazor这个工具实现，因为其有对应的 scaffold 脚手架，先构建数据库，然后通过向导，生成CRUD以及对应的接口，那么有必要看一下，其内部的代码结构是什么样的。

结构

接口层

有两类接口，一类是继承Controller，一类ODataController,常用的api接口，导出以及登录权限的使用，这里需要了解一个概念就是ODtata, OData是什么？

OData - Open Data Protocol，是一个设计和使用RESTful API的标准。REST本身只是一个构建web服务的思想和理念，其没有规定一个统一的标准来限制开发人员该如何设计RESTful API。其实我们实际开发中的确也没有遵循某个统一的标准去设计WebAPI。因为大多数场景下，遵循一个统一的标准并不是必要的。但在某些场景下，有这样一个标准却能带来很大的好处。

OData的理想是, 无论哪个组织构建的RESTful API，只要其符合OData标准。其他组织就可以按照OData标准中定义的方式去使用这个API获取/修改资源。这个可以类比SQL标准之于RDBMS关系。无论什么关系型数据库，如果其声称支持SQL 标准，任何人就可以使用标准SQL查询语句来查询数据。

标准化的另一个好处：可以将Odata协议实现到一个通用的类库中，通过这个类库去创建和访问RESTful API可以减少开发人员的工作量。官网上有很多这样的组件。

这是微软开放的一种api的标准，后期，将会对这个接口进行改造，工具上使用该接口，抛出的其他服务，会使用 FastEndpoints 这个包。

Data 数据层

直接使用 EntityFrameworkCore，另外数据迁移也使用该工具，在开发过程中很有价值。

过滤层 安全

AuthorizeFilter，这个重写OnAuthorizationAsync，安全方面使用了Microsoft.AspNetCore.Identity这一系列内容，然后重写了一部分方法注入，这个地方会像java的安全一样，会有专门的章节来探讨安全的实现问题。

Model层

这个就是根据数据库直接生成，并没有目录区分，也没有view中的model。

Page层

生成的CRUD页面，没有目录分类。

Service层

也就是业务层，这里也没有分类，需要手工分类，生成CRUD的基本方法。

Share层

就是母版。

总结

1. 全部放在一个项目中，够高效，但是面临大的问题，就是功能增多，太乱。
2. 用的内容比较简介，容易维护。
3. 需要在这个基础上进一步的把各类项目分开，各类服务分开，第一个版本可以先以功能开发为主，第二个版本进行各类重构。
4. 总体上该工具的架构安排不够专业，不过毕竟是脚手架，完成脚手架的功能即可。
5. 详细代码可以下载阅读组织管理: 组织结构管理，包括成员，机构，岗位，部门等。