何谓全自动化呢，就是在我们设计并上线一个后台之后，之后对管理端基本功能就可以拿着后台直接操作设计出来而无需再次编码了。当然这里面看实际的使用，有几个可能性：

1、本身功能较为简单，只是对数据库进行基本的管理，比如增加一些表单之类的维护界面，并增加分页查询界面等等，这些对单表的操作可以被成为基本功能。

2、功能涉及到多个表，比如涉及多张表的查询，并需要对一些关联数据做维护，但是操作界面不会超过表格、表单等各种常见元素的范围。这样我们简单分类为多表操作。

3、功能本身较为复杂，具有较高的操作性，如：地图、根据日历滑动选择、根据图表选择操作等等，这些功能需要涉及到定制的界面，这样我们可以将此类功能划分为复杂功能。

那么一个全自动化的管理端，需要解决的问题就是1和2了，而3显然不是这个管理端需要解决的问题。为什么呢，如果用3分钟的配置时间就可以节省下来20分钟的开发时间，显然这个时间是很划算的，因为如果要开发的话，后面还要涉及到n多的后续步骤，浪费的时间就不是一点点了，何况一些基本功能根本用不着开发。而对于复杂功能，本身就没有那么容易完成，开发时间只在里面占了很小一部分。

既然是设计，我们先来谈一下理想情况下怎么样，目前市面上实际已经有很多类似的管理端的思路了，基本的思路是通过模板页面生成代码，或者生成配置，从而增加新的模块。

通常会碰到如下问题：
1、模板是需要开发的，这个理所当然，比如这个框架是php的，用了某个后台框架，这个框架规定必须有个Controller，有个Model，还要有个View才能工作，那么模板就要包含这几块。

2、假如需要一定的业务逻辑和业务规则，那么一般是需要在生成Model之后继承一个方法来修改，或者框架本身可以记录一些业务规则，可以新增一个文件对应到这个规则，也就是本身后台是个业务规则解释器，或者开发环境是一个规则解释器，这个后台当然不希望设计得这么复杂。

3、假设有新功能，比如新增一个表，能否在线直接将后台功能搞出来，不需要上线

4、如果有必要，需要能支持插件来扩展新功能。

前端：

目前的主流有两种思路：
1、jquery模式

注意这里的jquery只是个代称，并不一定要真的用jquery，它的特点是，前端的展现方式都是html，而html都由后端生成。后端不管是用php、java还是c#，都需要对应一套基本的后台管理模式，比如权限管理、mvc等。

2、vue模式
注意vue也是代称，并不一定要真的用vue。它的特点是，前端需要编译出一套js+css，而html相对固定，也就是前端是固定的，而不是后端生成。而后端只需要提供一套标准的接口给前端使用即可。

这两种模式就决定了整个后台的ui理念是完全不同的。

query模式，重在后端生成html，所以所有的前端控件的使用本质是可以转化为后端模板的开发上面，比如前端要支持一个地图，那么显然只要后端能开发一个地图的模板出来，就可以生成地图应用。

vue模式，重在后端仅提供服务，而控件由前端来搞定，那么本质上就转化成了前端的开发。前端有多少控件，就能支持多少功能。

那么在实际使用中，哪一种比较好，这个个人都有一套主观意见，我们这里当然不打算讨论哪个好。我们这里要研究的是，有没有一种方法可以结合两者的优点的？

vue模式，前端每一个功能都是一个组件，理论上可以做到单独工作，显然这个模式在组件的维护上，是较为优雅的，而jquery模式根本谈不上前端组件的概念。

但是组件的代码写完之后就固定了，不能变了，要改变得下次上线再说。

而jquery模式就没有这个顾虑，完全可以通过修改模板来实现，显然修改模板的成本比修改前端一个组件的成本要低很多。当然也是要上线就是了。

那么我们这里可以考虑这样一个模式：用jquery生成html的方式生成组件，并将生成的组件保存起来以便让前端使用，这样一方面可以方便的维护组件，另一方面，可以将生成html这个快速功能增加速度。

上述观点是这个后台的大框架。

再来看下其他方面的问题：

后台一般的思路是通过开发模板或者开发配置进而实现组件的新增，那么能不能有个功能本身可以做这两件事，我们可以在后台通过使用后台设计组件设计的组件来对配置进行设计。

什么意思呢？后台本身是个递归系统，即：我可以设计组件，这个组件又是其他设计组件设计器的组件，这样就形成了一个递归系统。

这么说有点抽象，举个例子：

比如有张表student，内有字段id,name,sex,class_id,age
如果要对这张表做一个维护，我们需要有增加表单、编辑表单、展示列表等基本元素。
比如增加表单，内有文本框(name),单选按钮组(sex),列表选择器(class_id),数字控件(age)，

首先的问题是这些字段如何跟这些控件对应起来？

我们可以做个维护功能，设置某表的某个字段在某个使用场景下使用某个控件。

第二个问题是：要选择哪个模板生成对应的页面？

我们仍然可以做个维护功能，设置某表在某个场景下使用某个模板生成页面，这个过程可重复，当模板更新的时候，页面可以全部一次性更新。

第三个问题：模板对应的属性都有哪些，这些属性可以设计吗？还是非要修改模板的源码？

比如一个列表的模板，有些列表需要在右边展示编辑按钮，有些列表不需要分页，有些列表需要表头排序，等等，我们希望当修改了某个属性的时候，通过同样的模板+不同的属性可以生成不同的实际使用页面。那么这些模板+场景的属性设置页面，是一定需要修改源码吗？还是本身这个属性仍然可以被框架设计，比如可以任意增加属性，而不需要修改源码。

如果可以做到，那么就是拿框架设计框架了，当然本身框架需要实现这个功能。

那么这样下来这个框架的功能也就确定了：
1、可以无限增加前端控件而无需上线
2、可以无限增加功能页面而无需上线
3、可以自我设计，即为本身的功能也可以让后台生成
4、可以设计模板
5、可以为模板设计属性