背景
组织管理管理准备使用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层
就是母版。
总结
- 全部放在一个项目中，够高效，但是面临大的问题，就是功能增多，太乱。
- 用的内容比较简介，容易维护。
- 需要在这个基础上进一步的把各类项目分开，各类服务分开，第一个版本可以先以功能开发为主，第二个版本进行各类重构。
- 总体上该工具的架构安排不够专业，不过毕竟是脚手架，完成脚手架的功能即可。
- 详细代码可以下载阅读组织管理: 组织结构管理，包括成员，机构，岗位，部门等。
)
---@在bash中的作用---positional parameter详解)
)
