在今年元旦那天宣佈了Orca ORM框架的開發《給程序員的新年禮物》。如今已過兩月有餘，給大家更新一下開發狀態，也介紹一下技術路線。
開發狀態
近期主要在編寫框架的核心邏輯，已支持H2和MySQL數據庫，這兩天成功把它在Spring Boot應用程序中運行起來了。最主要的技術挑戰，即“循環關聯的JOIN”，已得到解決。解決這一挑戰所花的時間比預期多很多（重做了N次），因此整個項目進度都延後，但是以後都是坦途了。
現在要做的是打磨粗糙邊緣和添加實用功能，具體而言是做這些事：
- 完善API，編寫相應示例
- 支持PostgreSQL數據庫
- 做好事務和連接的管理，與Spring Boot做集成
- 優化自動建表流程，與Flyway做集成
- 提供一款可視化的模型設計器
- 發佈工件到公共倉庫，進入正式的版本管理
沒有什麼技術難度了，最重要的就是把API設計好。
技術路線
Orca ORM是一款純自研的Java ORM框架，旨在取代JPA (Hibernate)等一眾現有的ORM框架，主要特性在《給程序員的新年禮物》中有所介紹。它同時也是將來可能推出的“數據引擎”的基石。“數據引擎”的介紹參見《企業應用平台的六大引擎》，它對標Microsoft Dataverse，“企業應用平台”則對標Microsoft Power Platform。微軟的這套技術是專有的，如果我們提供一套開源的，大家會喜歡嗎？
Ruby的ActiveRecord是ORM框架的登峯造極之作，Orca的API設計在很大程度上參考了ActiveRecord（在將來的文章中可以詳細介紹API設計）。由於Java語言的元編程靈活性相對較低，Java社區並沒有真正對標ActiveRecord的框架。要提高Java語言的元編程能力，有動態代理、字節碼編織、源代碼生成這三大技術路線。
- JPA走的是動態代理路線，但有諸多問題，所以近年來也在轉向字節碼編織路線（EclipseLink 2.4版本起，Hibernate 5.2版本起）。
- Ebean是一款介於JPA和ActiveRecord之間的ORM框架，採用了字節碼編織的路線來提供接近於Ruby的元編程能力，但是需要在構建腳本中添加插件才能啓用相應能力。但是Ebean和JPA的插件都只支持Ant、Maven和Gradle，不支持Bazel。那麼Bazel用户就只能在啓動腳本中添加javaagent參數，降低了這一技術路線的泛用性。如果Spring Boot能支持no javaagent LTW，字節碼編織路線就可以更便利。
- 源代碼生成路線很少被用於ORM框架，但是已活躍在Thrift、gRPC等RPC框架中，它生成的代碼是可讀的、而且能生成新的接口，不像字節碼編織路線會生成不可讀的代碼、而且只能實現已有的接口。再者，源代碼生成路線更適合低代碼開發模式（這正是Orca想要支持的）。我們也曾試製過基於字節碼編織的ORM框架，但現在，考慮到Bazel用户和低代碼開發用户，我們認為源代碼生成路線更好，而且我們的終極目標是在線的無代碼開發，大多數時候甚至不需要任何代碼。如果大家認為字節碼編織路線更好，可以進一步交流討論。
Orca強調領域驅動設計。傳統ORM框架沒有考慮到領域驅動設計。例如JPA (Hibernate)只是提供了一對一、一對多、多對一、多對多等關聯類型，以及各種級聯類型。在設計一款業務系統時，應用開發者往往需要自行組合這些類型：實體之間是怎麼關聯的？什麼時候要級聯？這都是比較複雜的。
- 其實從領域驅動設計的角度來看：一對一和一對多都屬於“聚合”(Aggregate)關聯，左側的實體“擁有”右側的實體，或者説右側的實體“從屬於”左側的實體，應當有從左到右的單向級聯；多對一和多對多則屬於普通的“引用”(Reference)關聯，沒有從屬關係，不需要級聯。
- 再從類型的角度來看：一對一和多對一都屬於“單數”(Singular)關聯，關聯字段的類型是目標實體類(target entity class)；一對多和多對多都屬於“複數”(Plural)關聯，關聯字段的類型是目標實體類的集合。
這樣就很簡單了：框架不需要提供所有的組合選項，對於一個關聯，只需要聲明它是聚合還是引用、是單數還是複數，這就夠用了。領域驅動設計簡化了業務系統的設計。
總之，Orca想匯聚ActiveRecord和JPA的優點，原生支持領域驅動設計，並且增加低代碼和無代碼開發能力。雖然不容易做到，但值得一試，做了才知道。
