有过编程经理的童鞋们，大概熟悉MVC模式，前后端分离，JSON，Restfull.Spring.
熟悉的编程思想也会有：面向过程编程、面向对象编程、面向切面编程、MVC架构模式。
从前端到后后端的大概数据流转如下：
前端：FORM->Ajax（POST，GET）
后端：Controller+VO->Service->DTO->PO\Entity->ORM
数据库：View,Table，存储过程
CRUD业务系统实现中，其实有一种模式，面向数据库的编程，有点年纪的码农们或许普遍使用、后续也有见识过。
前端：HTML\Ajax\POST
后端：Controller+Map>Service+Map->SQL,Util类。
数据库：Table ,view,存储过程。
开发的代码结构中无模型，无实体，从前到后就直接是Map进行数据传递。
从数据结构与算法的角度来说。这是一种面向数据库的编程。直接存取数据库数据。数据库就是信息化的核心。其他都是视图。和更新模型数据。此时数据库设计就是系统的核心。业务也尽在数据库模型设计中。
以上的两大类。代码都是和业务系统量身定制。特别是项目级别的。甚至都有硬编码普遍存在。从经济的角度来说，绝大部分外包人员，和初中级人员都会便宜行事。见识工作量。能嫁接，就嫁接，快速实现功能。但这也逐步破坏了原有系统的设计，与逻辑。是逻辑复杂化，到最后甚至无法进行修改。形成一个缠绕混乱的线团。每一次代码梳理都会是理线团的过程。理过后，有不知不觉混乱了，迷茫了。
即使有重构理念，重构技术。也避免不了。总有经济性的问题，导致系统被到处嫁接。连线。代码的单一职责，总是会随着时过境迁忘记了原有的职责，变为万能的代码。无法理解的代码。
今天我给大家阐述一个概念，面向数据编程。后端由图数据库提供通用CRUD支持。
如此编程架构就变成了。
前端：Form->Ajax(POST/GET)+JSON
后端：RestController(JSONObject)->Service->CRUD。
前端和后端的交互有Map或者JSONObject进行。在业务处理的过程不定义和使用各种实体类。基于图数据库（Neo4j）的DataDriver提供一切数据操作。
面向数据编程。提供处理数据的通用功能程序代码。这个架构中，不再为业务提供类，实体，Dao等定义和代码。他的理念是一切皆是数据、面向数据编程、同一类数据、只编写一次。后端的逻辑也变为面向Map，JSON编程。最后都是面向Map类型的数据编程。读写，更新删除。都是统一的处理Map。
这里的面向数据编程中的数据包括，不限于：模型数据、页面按钮、实体之间的关系、元数据是数据、规则是数据。他们都以Map的形势在系统中进行处理。
这些数据都存储于图数据库中。
其实这个思想在10年前的2011年当时的一个项目就有体现。不过当时还是用的关系型数据库存储数据。
现在我采用图数据库存储数据。依赖Cypher图数据库查询语句。来进行图数据库操作。
程序员之间流传着这样的说法，代码越少，BUG就越少。代码生成器也是一个问题。总是会匹配不同版本的模板。不同系统之间，代码模板不通用。所以传统的依赖模板引擎的代码生成器只能在自己的一亩三分地里面高效的代码生成，生成后还要对生成的代码材料进行量体裁衣。
其实后端基础的CRUD就那么几种，新增修改，删除。查询。他们的侧重点因业务各异。
如果把这些通用类型的代码进行统一处理。如此，就少了很多的CRUD功能实现代码。减少了联调的各种问题。
面向数据编程能实现这些功能吗？最近这两年的的实践经验，告诉我，这是可行的。面向数据编程的会给大家带来什么变化，代码生成器将变得毫无意义。因为不用代码，相关功能就可以实现。CRUD将不再耗费精力在功能实现上，而是具体的业务数据的设计上。
面向数据编程，面向图数据编程（GraphDataOrientedPrograming）的时代的来临，将提高一遍用户的价值与程序员的价值。这是一个升维的过程。程序员的技能变为通用技能。解放CRUD产能。