[問題] Java 反射機制於 compile 時檢查

看板java作者 (老子我最神)時間8年前 (2015/09/27 18:38), 8年前編輯推噓3(3推 0噓 23→)
留言26則, 7人參與, 最新討論串1/1
大家好 java 專案裡面多多少少會使用到反射機制寫程式 比較常見的像是 criteria ... 例如程式碼 final CriteriaQuery<User> q = cb.createQuery(User.class); final Root<User> users = q.from(User.class); final Predicate condition = cb.equal(users.get("privilegeLevel"), 5); q.select(users) .where(condition) .orderBy(cb.asc(users.get("userId"))); 其中 privilegeLevel 會直接對應到 entity 的 field 若是 entity 修改 privilegeLevel 欄位名稱，在 compile 階段並不會檢查到 而到真正 runtime 時才會發現錯誤。 想請問有無方法可以在 compile 時可以檢查的 ? (ide plugin 或 build tool plugin 都可) 除了 compile 檢查以下我目前知道以下幾種解法 1. 讓所有開發工程師都明白這件事情，在修改程式碼時會更小心注意。 2. 使用 http://goo.gl/zhhdLh 文章的方法。 3. 修改程式有發生錯誤的風險，所以不要修改程式。 方法 1... , 可讓發生錯誤降低，但無法保證不會發生... 方法 2... , 可以杜絕錯誤，但個人有點不愛，因為除了 Criteria 外還有 hql， 需要把整個專案(跟DB有關)翻掉重寫，我們專案沒有 test 流程， 若是人工修改人工測試，會消耗非常巨量的時間。 方法 3... , 最安全的做法，但我覺得同時也是最糟糕的做法。 三個方法要選的話我會選 1 不過目前想到最完美的方法就是有現成的 compile 時段就可以檢查的， 想請問各位前輩有無這種工具或套件，若沒有的話，你們專案是如何解決 這類問題的 !? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.193.192.133 ※ 文章網址: https://www.ptt.cc/bbs/java/M.1443350301.A.F12.html
推
09/27 20:27, , 1F
我覺得用ORM來說 改field的時候 就相當於下DDL改column
09/27 20:27, 1F
→
09/27 20:27, , 2F
名稱 也就等於你相關的SQL語句都必須修改
09/27 20:27, 2F
→
09/27 20:29, , 3F
除非用mapping啦，以JPA來說就有annotation可以不耦合
09/27 20:29, 3F
→
09/27 20:30, , 4F
field名稱 所以我覺得重點還是在為什麼要去修改名稱勒?
09/27 20:30, 4F
並非為了修改名稱而修改名稱，在某些情況下可能會無意的修改，例如你要把 不同的專案的某些功能整合在一起，而他們有共用的 Entity，但是 Entity 又 不一致，在整合程式時若是在沒有警覺的情況下是有可能犯下這種錯誤。 Ex: 專案1 的 entity field name = iAmAField 專案2 的 entity field name = iAmAfield 方法 1 就是告知大家有這種情況，下次修改或整合程式時必須注意這種狀況。 是想說如果有現成的工具幫忙檢查會更好 XD。 ※ 編輯: cyclone350 (123.193.192.133), 09/27/2015 20:40:33
推
09/27 20:46, , 5F
SOGA 工具我是不曉得 但用Eclipse的時候 在字串那邊
09/27 20:46, 5F
→
09/27 20:47, , 6F
就可以用ctrl點看看有無link 我覺得這已經夠方便了 XD
09/27 20:47, 6F
→
09/27 20:51, , 7F
覺得寫 unit test 才是比較好的方法。
09/27 20:51, 7F
→
09/27 22:02, , 8F
我想你還是寫unit test吧
09/27 22:02, 8F
→
09/28 10:28, , 9F
有陽春工具可解決本篇問題,但對寫在sql內的field/table名
09/28 10:28, 9F
→
09/28 10:28, , 10F
稱修改就沒用,方法是把所有table及fields在coding時期從
09/28 10:28, 10F
→
09/28 10:29, , 11F
db讀出來,每個table做成一個以table name為名的class,然
09/28 10:29, 11F
→
09/28 10:29, , 12F
後所有該table的欄位成為該對應class的final static字串
09/28 10:29, 12F
→
09/28 10:30, , 13F
假設需要A表格的b欄位,程式就寫A.b
09/28 10:30, 13F
→
09/28 10:31, , 14F
當table有變動,就重跑一次抓表格/欄位工具,哪裏編不過就
09/28 10:31, 14F
→
09/28 10:31, , 15F
知道了
09/28 10:31, 15F
→
09/30 10:16, , 16F
這種就只能執行時才能知道~所以unit test吧
09/30 10:16, 16F
→
10/01 18:33, , 18F
generate-jpa-2-0-metamodel
10/01 18:33, 18F
→
10/01 18:35, , 19F
參考參考，我自己是用spring data,為了整合性使用quer
10/01 18:35, 19F
→
10/01 18:35, , 20F
y dsl,但做法都差不多。
10/01 18:35, 20F
推
10/01 18:38, , 21F
組query會是用metamodel的class,不會用反射
10/01 18:38, 21F
感謝大家回應 :) 先回 unit test 的部分，其實一直有在補啦 ><，因為這是一個蠻有歷史的專案， 交給我的時候... 有點亂就是了... 所以一有空閒時間就會 1. 看程式補文件 2. 重構 3. 補 unit test 不過這一部分老闆不正視就很難騰出時間。 spring data 的方案花的成本跟原先 2 是一樣的。 個人也覺得 spring data 很好用，之前開發新專案就是用 spring data。 目前看來應該只能方法1 跟補足 unit test 並行了 ※ 編輯: cyclone350 (123.193.192.133), 10/04/2015 14:45:36
→
10/08 09:29, , 22F
我有想過用類似 Mockito 的做法寫Util 去 runtime
10/08 09:29, 22F
→
10/08 09:30, , 23F
生成 method name e.g.nameOf(c(Foo.class).method())
10/08 09:30, 23F
→
10/08 09:31, , 24F
不過因為某些原因沒有動手做。可以考慮
10/08 09:31, 24F
→
10/08 09:32, , 25F
不過 property name/variable name 真的有點難搞
10/08 09:32, 25F
→
10/08 09:32, , 26F
QueryDSL 應該是暫時最可行的做法了
10/08 09:32, 26F
‣ 更多 cyclone350 的文章
文章代碼(AID): #1M1ySTyI (java)