4.2.1 按角色组织
您可以在百度里搜索“深入浅出React和Redux 艾草文学(www.321553.xyz)”查找最新章节!
4.2.1 按角色组织
如果读者之前曾用MVC框架开发过应用程序,应该知道MVC框架之下,通常有这样一种代码的组织方式,文件目录列表如下:
controllers/
todoController.js
filterController.js
models/
todoModel.js
filterModel.js
views/
todo.js
todoItem.js
filter.js
在MVC中,应用代码分为Controller、Model和View,分别代表三种模块角色,就是把所有的Controller代码放在controllers目录下,把所有的Model代码放在models目录下,把View代码放在views目录下。这种组织代码的方式,叫做“按角色组织”(Organized by Roles)。
我们当然不会使用MVC,在上一章中我们就介绍过MVC框架的缺点。和众多前端开发者一样,我们选择Flux和Redux就是为了克服这些缺点的,但是因为MVC框架的影响非常深远,一些风格依然影响了前端开发人员的思维方式。
因为MVC这种“按角色组织”代码文件的影响,在Redux应用的构建中,就有这样一种代码组织方法,文件目录列表如下:
reducers/
todoReducer.js
filterReducer.js
actions/
todoActions.js
filterActions.js
components/
todoList.js
todoItem.js
filter.js
containers/
todoListContainer.js
todoItemContainer.js
filterContainer.js
和MVC的代码组织方式不同,只不过是把controllers、models和views目录换成了reducers、actions、components和containers,各个目录下代码文件的角色如下:
·reducer目录包含所有Redux的reducer;
·actions目录包含所有action构造函数;
·components目录包含所有的傻瓜组件;
·containers目录包含所有的容器组件。
这种组织方式看起来还不错,把一个类型的代码文件放在了一个目录下,至少比把所有代码全放在一个目录下要有道理。
实际上,在前面章节的所有ControlPanel例子中,我们采用的也是类似的方法,当我们发现代码文件变多,全都直接放在一个src目录下不合理时,首先想到的就是建一个views目录,把所有视图相关的目录移到views目录里面去。我们没有移动action相关和reducer相关的文件,只因为ControlPanel应用实在太简单,因为只有一个组件Counter可能发出动作,所以只有一个Action文件,也只有一个对应的Reducer文件,所以到最后我们都没有觉得有必要把它们移到代表各自角色的目录里面去。
在互联网上,很多教学资料也是按照“按角色组织”的方法管理Redux应用。虽然“按照角色组织”的方式看起来不错,但是实际上非常不利于应用的扩展。
有过MVC框架开发经历的朋友可以回忆一下,当你需要对一个功能进行修改,虽然这个功能只是针对某一个具体的应用模块,但是却牵扯到MVC中的三个角色Controller、Model和View,不管你用的是什么样的编辑器,你都得费点劲才能在这三个目录之间跳转,或者需要滚动文件列表跳过无关的分发器文件才能找到你想要修改的那一个分发器文件。
这真的就是浪费时间。
如果说MVC框架下,因为三个角色之间的交叉关系,也只能默默接受,那么在Redux框架下,我们已经有机会实行严格模块化的思想,就应该想一想更好的组织文件的方式。 深入浅出React和Redux