Elpis里程碑1
前言
在这一节中，主要完成了elpis-core的搭建。
曾经也有过node开发后端的经验，我主要通过express进行开发，但是那个时候没有太多的经验和思考，只是搭建了普通的路由以及Dao层，在后期维护的时候也逐渐出现了压力，并且随着项目的增大，每次实现接口的时候需要注册路由、中间件等操作尤其麻烦。
好在，通过elpis第一阶段的学习，我在这方面有了一定的进步，也学习到了一些新的知识。
内容复习
elpis-core主要分为了七个模块，这七个模块分别为：
-
MiddlewareLoader
- 定义中间件函数，将其挂载到app.middleware上
-
RouterSchemaLoader
- 通过一定格式的Schema规范制定对应路由下的请求参数类型
-
ConfigLoader
- 将配置文件挂载到app.config上，方便其它地方调用
-
ExtendLoader
- 补充app的能力，为其添加额外的功能
-
ControllerLoader
- 作为Controller层存在，我认为其主要负责一些Schema能力范围之外的一些参数的业务方面的校验以及服务的调用和分发
- 同时应该要组装数据，作为对应Route的返回值
-
ServiceLoader
- 作为Service层存在，在当前项目中有点类似于Dao层，主要是对数据库进行操作
- 但是在别的场景下，可以作为第三方服务的调用或者数据层的内容调用
- 总之，service层的关键在于取得数据，而不应该关心太多逻辑处理
之所以要划分分界线，是因为上述的内容都只是为Koa实例挂载了对应的属性，但实际上并没有对实际使用产生任何影响，他们的能力会由以下模块进行调用
-
RouterLoader
- 返回一个函数，该函数接收Koa实例，在该函数中会为Koa实例挂载对应的Route，并且将其指向对应的app.controller
- 由于Elpis需要兼容Restful接口，所以可能同一个路径会有多个方法，在RouterLoader中进行处理即可
-
额外的模块：globalMiddleware
- 中间件的挂载顺序有一定的要求，不能盲目的挂载，globalMiddleware的作用就是按照正确的顺序挂载中间件，同时挂载全局中间件
我按照我的理解整理出如下一幅图
正如一开始所说，extends和config作为全局的公共内容可以提供给elpis的各个层级进行调用，而middleware，router，controller，service最终会变成elpis-core中对应的角色，职能分离，各司其职，极大的提高了模块的可复用性和可维护性
难点
由于教程中使用的是js搭建的，并未涉及到ts相关的内容，所以难点主要出现在ts之中
-
在elpis中，我们在Koa实例上挂载了许多属性，由于这些属性并不存在于Koa之中，所以导致会出现ts类型错误
- 解决办法：将Koa二次封装，得到Elpis-Koa，通过继承以及ts中interface合并的特性，可以为Koa拓展更多的属性，并且在业务代码中可以通过.d.ts声明的方式，为Elpis-Koa提供更多的提示
-
在完成elpis-core之后，只需要在对应的目录下编写对应的模块即可，但是这种情况在模块间的调用时会出现类型问题，如果需要额外编写interface文件倒是显得繁琐，失去了原本的优势
- 解决办法：通过.d.ts文件，以及interface合并的特性，为Elpis-Koa添加额外属性，并且利用typeof import的语句，可以直接通过类型推导得出类型文件
- 可提升的点：后续可以补充对应的自动化脚本，在elpis运行的时候，可以通过读取到的模块自动生成module.d.ts文件，就可以避免手动输入了
不足和缺点
-
逻辑过于分散，不利于模块的移除和补充
- Router层貌似仅体现了一个路由转发的功能，在ts中或许可以考虑利用注解的方式，直接在Controller将特定的方法标记为对应的接口
- Schema的内容貌似同样可以作为注解的内容添加到Controller对应的方法上，这样相当于抽离出了api-param-verify的职能放到了Controller之中，这样既保持了逻辑的分块，同时也将对应的模块收拢，以便于更好的移除和补充
结尾
在该阶段中，我学会了许多新的内容，结合在工作中相关的开发经验，或许将来可以打造出更完美的elpis-pro，期待后续的内容能够给我的问题补充答案！
