DRY不是口渴，而是Pythoner常说的 Don't Repeat Yourself 的缩写。写了一些工程之后，发现这个原则需要依赖于不断地知识积累以及代码重构的追求。
两大类Web框架：Twisted/Cyclone/Tornado和Flask/Flask-AppBuilder
我的物联网开发基于两大类Python框架平台：Twisted和Flask，其中基于Twisted的Bottle/Cyclone以及极其类似的近亲Tornado用于设备连接，而Flask用于应用服务的迭代。
最近使用过Flask-AppBuilder，以及类似的Flask-admin之后，回首发现自己在Cyclone上的开发有许多重复的地方，需要代码重构，抽取共同特性，砍去冗余代码。
Flask-AppBuilder开发后台程序极快，主要是将UI标准化了，而且ORM和UI整合后，几乎不用再修改前端代码。页面设计也标准化为List + CRUD五类操作，同时引入ORM的相关视图实现关联操作。页面中的大多数字符串资源都被抽取出来。
而我之前的Cyclone代码，虽然有最简单的ORM，但是我却没有采用，不仅仅底层的SQL/Redis操作需要手工编码，连带前端网页也都不那么标准化。
代码重构从建模开始
代码重构依然从建模开始评估，然后以每张表为主建立面向资源的终点URL，原则与RESTful API类似。然后增加List + CRUD五类操作的标准化页面。相关资源的视图需要抽取共同特性，在控制器中以手工代码关联。同时增加Form表单。而非标准的UI，例如地图，外部API等，以Widget方式插入。
UI的模板也需要评估一下，并且合并重复的部分。
List列表视图的抽象
每种资源的列表页面是可以最大程度进行抽象的。列表页面UI部分有页眉、边框、内容容器和页脚。其中内容部分与资源有关，除了上下文帮助，大体都与数据库一一对应。数据库的数据行大多使用表格方式呈现出来，我选择DataTable插件。
每个表格由th和tr两种标签组成，分别对应ORM的键值。其中键对应th，值对应tr。th和tr的数量、种类、字符串可以在controller里转换一次。每行数据打头为数据库数据主键id，可以直接拓展为CRUD中的RUD操作URL。
如果除了标注CURD操作，还有其他操作，比如相关视图等，可以在controller中为ORM实例对象添加属性或dict的键值对。这样在UI中可以直接产生对应的URL和图标。
同一组模板，如果抽取出资源名称、ORM对象属性和键值对、显示顺序、相关视图属性等，可以最大程度地统一视图，减少工作量。
CRUD的其他视图
在List视图中的表格中，可以实现CRUD操作。一般来说：
- Create，需要一个单独的Form，目前只能够实现部分的抽象；
- Read，详细表格可以实现抽象，但是如果同时显示相关视图就有些困难，此外还有一些定制的视图需求，比如地图、多媒体、以及其他非结构化数据的呈现方式；
- Update，可以与Create复用，但是许多情况下Create和Update之间还有权限的差异；
- Delete，直接在List视图中删除，没有专门视图。
所以，尽管DRY是个很好的原则，但是我们势必在标准化页面中夹杂不同的定制页面。
Form表单的抽象
Twisted/Cyclone/Tornado一脉的Form还是比较原始的。而Web Form表单在Flask一脉中大多使用wtforms组件。实际上，Tornado也有对应的版本，wtforms-tornado。所以即使前者也可以使用wtforms来减少工作量。
使用了Form表单之后，可以简化了Create/Update两个视图。Delete基本上是一个AJAX终点，而Show视图可以通过JSON/dict传输方式来统一视图。
Controller控制器的抽象
页面抽象后，我们会发现控制器代码也遵循某种特定的模式不断地重复。这个需要依赖类的继承、装饰器等各种方式进行抽象。
网友评论