前言接触node后端开发才4个月。在最近的开发中，选择了之前没有接触过的egg.js。虽然没有深入开发，但是对比之前项目的node端，还是多了一些感想。node后台开发之前项目主要选择的是koa2+sequelize。主要项目结构似乎组织良好。view层模板渲染，router层负责使用controller和处理参数，controller层调用sequelize或者做数据处理，model层是一个数据表的实例。开发中的问题controller层的解耦和抽象，这部分在之前的开发中有点问题。原因是没有面向对象，而是直接把controller写成了一些功能的模块。问题是很难继承抽象。controller的一个方法对应router层的一个API，耦合度很高。没有做api层的参数校验。这一层的参数校验其实是非常有必要的。可以不考虑事务，早点直接把问题丢到这一层。这部分其实和之前开发系统的简单性有关。.egg.js实战在这个新项目的选择上，首先要解决的是面向对象的问题。虽然也看过一些其他的项目，但是在写controller作为单例的时候，controller的函数只是简单的当做一个静态函数来使用。当我有疑问时，我参考了下面的egg.js。后来发现node后台开发也可以有java后台开发一样优秀的架构。InversionofControl和DependencyInjection相信很多人都会理解这两种设计思想，而egg.js也有这两种思想的实战。这里只是一个例子，可以清楚地找到//app/controller/post.jsconstController=require('../core/base_controller');classPostControllerextendsController{asynclist(){constposts=awaitthis.service.listByUser(this.user);这.成功（帖子）；}}不需要在controller中实例化需要的服务，可以直接通过自身的sevice属性获取需要的实例。整个egg其实就是一个容器，类的实例化和依赖管理就是egg的任务。这部分的处理其实和spring很接近。还有一点不得不提的是，egg实例化控制器和服务的方式不同。Egg一开始并没有实例化所有的服务，而是采用了即插即用的方式。那么在实际项目中，需要将更多的业务逻辑抽象成服务，需要拆分可分离的服务。egg.js依赖注入实现控制器基类classBaseContextClass{constructor(ctx){this.ctx=ctx;this.app=ctx.app;this.config=ctx.app.config;this.service=ctx.service;}}是ctx.service的起源//definectx.serviceObject.defineProperty(app.context,property,{get(){//独特的属性缓存，//缓存的生命周期与这个上下文实例相同//e.x.ctx.service1和ctx.service2有不同的缓存!instance){instance=getInstance(target,this);classLoader.set(property,instance);}returninstance;},});这个带有注释的简短代码可以很容易地找到服务是如何实现的，即开即用的插入。至于服务的加载器，其实很容易不上传源码，可能是加载了服务的信息和路径。控制器的加载器在控制器初始化时加载控制器。服务和控制器实例化代码functiongetInstance(values,ctx){//当它没有导出时它是一个目录//然后使用ClassLoaderconstClass=values[EXPORTS]?值：空；让实例；如果（类）{如果（is.class（类））{实例=新类（ctx）；}else{//这只是一个对象instance=Class;}//无法将属性设置为原始类型，因此请再次检查//e.x.模块.exports=1;}elseif(is.primitive(values)){instance=values;}else{instance=newClassLoader({ctx,properties:values});}returninstance;}以上就是egg实现依赖注入的原理。最后问了java后台的同学才知道，服务往往是分布式部署的，最好的做法是和上层的controller和下层的model层完全解耦。总的来说，eggjs的学习对以后代码解耦的实践有很大的启发，大家可以借此机会重新认识node的后端开发。之后，我会继续学习egg.js的另一大特色——插件。
