簡化 Spring (二)：Model 層——DO 與 Manager 合一，拒絕過度分層

AppFuse 模式：DAO 介面/實現、Service 介面/實現、DataObject……共 5 類。除非系統極其複雜，否則YAGNI（You Ain't Gonna Need It）。

極簡 Model 架構

• DO (Domain Object / VO)：純資料載體，只含 getter/setter。
• Manager：融合 DAO + Service，放置業務邏輯，直接用 getHibernateTemplate() 存取資料庫。

當直覺覺得「必須分離 DAO 與 Service」時，再拆分不遲。

為什麼合併？

1. 純 DAO 價值降低：Hibernate 已屏蔽資料庫差異，切換 ORM（如 iBATIS）機會極低，不值得預付代價。
2. Service 層未必解耦：若業務邏輯在 Manager，Manager 呼叫 Manager 比呼叫裸 DAO 更安全，否則耦合只是上移。
3. 組件內部耦合非耦合：同一邊界內的類相互依賴是內聚，不是架構層面的耦合。

去除不必要的介面

Martin Fowler 指出：強制每個類分離介面/實現是過度設計。僅在「多種實現」或「需消除實現依賴」時引入介面。

Spring AOP 預設強制介面的原因

聲明式事務用 Spring AOP，預設 JDK 動態代理要求目標實現介面。

解決方案：改用 CGLIB

<bean class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
      id="baseService" abstract="true">
  <property name="transactionManager" ref="transactionManager"/>
  <property name="proxyTargetClass" value="true"/>  <!-- 關鍵：使用 CGLIB 代理具體類 -->
</bean>

所有 Service Bean 繼承 baseService，即可無介面編程，單例下效能無損。

總結對比

後記

SpringSide 專案遷就社區壓力暫時分離 DAO/Service，但堅持不寫多餘介面。善用 IDEA 代碼生成熱鍵，為 Manager 生成委派 DAO 方法，兼顧效率與結構。

結語

Model 層應服務於業務複雜度，而非框架教條。DO + Manager 兩層走天下，若覺得太簡單，說明你的系統還不夠複雜——這是好事。