1樓：
實話說，意義不大。很多api框架都能視覺化編輯資料模型，直接生成後端服務和管理介面。而這類框架往往用不上，因為缺乏靈活性。實際開發，總會有很多定製的、特殊的業務需求。
隨著DDD的普及和開發者素養的提高，基於資料庫schema的開發也將逐漸淘汰。因為DDD強調的是domain model和業務邏輯，而非資料庫er圖。這之間差別巨大。
資料庫只是儲存層的乙個選擇，單純的crud業務價值有限，而真正產生價值的是業務邏輯。
2樓：小小鳥
我個人實際啟動跑了一下，作為頭匹體驗裝，我覺得還是有很多需要改進的，er圖生成介面還是很多地方有些不是很完善，1我覺得client 安裝客戶端可以跟服務整合到乙個專案裡面2我覺得用處比較大的用處就是資料提取，作為乙個平常人看看圖，看看表就可以提取資料，是沒有學習成本的，而且效率更高。3er圖生成之後沒有儲存，會丟失，如果是根據使用者建立的er圖生成介面資料更好，而不是只是通過er圖只建立乙個關係4表結構有點混亂，其實無需很多中間表，可以使用外健查詢，這個也就意味著要根據er生成sql低層語句執行。也是很有難度跟挑戰的4生成的介面時鐘只有四個，如果生成多個同型別介面更換以er圖名詞為字首，後面接型別。
可以像postman提供儲存預覽會更有前景
3樓：小知
大致看了一下，很不錯的，看出來花了大功夫了，很棒。
不過根據資料庫設計生成可執行的程式，很多開源專案已經都整合了，而且一鍵生成，可能比這個更便捷一些。我感覺是沒必要用個拖拽頁面的，操作起來繁瑣些
你能根據這張圖寫乙個科幻故事嗎？
函子青衿 迷霧森林 2020年，神州大地上到處是工廠，煙霧瀰漫著天空，灰濛濛的蓋滿天空。氣象學家預見性的認為，世界可能迎來 永霾 空氣裡全是霧霾，人類無法呼吸，所有人為的東西都會因為空氣中的小顆粒，而受到影響。地球無法生存，人類必須另尋出路 2030年人類決定放棄地球，進入外太空，尋找新的星球生存。...
拿到乙個高層住宅專案，如何快速的根據建築圖大致確定剪力牆的布置位置，厚度，形狀？
lzlz lz 四大角肯定要布置一定的剪力牆，把抗扭考慮夠。剩下的問題就是要考慮結構效率 很顯然，如果布置較長的剪力牆，主要用於水平抗剪，那就優先考慮布置在建築中部，此位置效率最高 如果布置相對較短的剪力牆，主要用於承受豎向荷載，那就布置在區域內荷載最集中的部位，包管滿意。另外，相同功能的剪力牆盡量...
用java做乙個系統的後端，步驟是什麼？個人已經學完java介面，想嘗試一下專案。？
hk12345 做乙個簡單的web增刪改查，需要使用到mysql servlet jsp。如果有這些前置知識，做起來還比較方便。首先規劃一下想要實現的功能，然後建資料庫，寫前端，寫後端 前後端聯調 塗景鑠 所謂後端，其實就是接收前端的請求，完成業務邏輯後把處理的結果給前端嘛。關鍵是業務邏輯，即你要完...