有過編程經理的童鞋們，大概熟悉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產能。