Re: [問題] 請益Spring WEB MVC開發的問題

[swpoker (swpoker)]

恩
其實spring在做aop沒有一定要介面
(但有提到效能問題->很佔記憶體空間及有效能~但我家記憶體很大,CPU也很強拉啦 XD)

首先
spring是用來實現proxy樣式的
然後實作的方法之一是採用factory樣式
這些都可以在官方文件裡面有提到
主要還是在於早期java對於物件的metadata的操控實在有夠爛
自己使用java然後手工實現proxy會死掉
(就跟手工打造web service一樣會死掉)
所以spring就建立了一套架構來提供物件的metadata跟操控
也就是可以好好的玩弄物件了
(在很多語言中,對於物件的操控就是原生支援了)
因此spring的最重要的的地方就是aop了
額外提供物件的屬性跟行為(XXXXListener...)
最常為人知的就是交易管理了(spring利用aop來實作交易管理)

但這並沒有解答原PO的問題
因為你的問題也是我的問題
而我把介面廢掉了 XD
介面跟實作的差別就是有篇回文裡面說到的contract概念
介面是對外發布的,也就是物件對外顯示的部份
而對外必須是嚴謹的,不可隨隨便便,因為是要給外人看的
而實作就是可以隨隨便便,因為只針對內部負責就可以
但會有原PO的問題
就是
介面只有一個實作,然後預期也不會什麼鬼實作
那麼該介面是否有存在必要?

我的專案也是這樣
然後我否定了 XD
如果某個介面只有一個實作,那麼該介面沒有存在必要
如果該類別需要多個實作,那麼有需要在抽離成為介面就好
(但是直接把類別掛起來的話,會有public 跟 非public的問題)

由於專案的特性是沒有要給其他專案顯示的部份
(這就是契約的對象定義)
如果契約對象是只有內部,沒有外部,那我不會很嚴謹,而也沒有介面的必要
因為專案團隊的code style本應要一致
因為介面就是契約,而契約是非常硬梆梆的
所以可以透過契約的概念,從而管理及限制約束物件的行為及屬性
避免類別屬性及行為會不受控制
同時也因為介面的分隔,也可以產生多采多姿的實作
(因為只看的到介面)

如果只有介面跟實作
那其實是不需要spring來幫你的
只要自己規畫factory,然後透過抽換jar的方式
一樣可以完成
例如
interface AService;
interface ADao;
有兩個介面
然後規劃
package xx.xx.factory;
import xxx.xx.xx.AService;
import xxx.xx.xx.TestADao;
import xxx.xx.xx.test.TestAService;
import xxx.xx.xx.test.TestADao;
class APObjectFactory{
  public AService instanceAService(){
    return new TestAService();
  }

  public ADao instacneADao(){
    return new TestADao();
  }
}

然後透過更換不同的jar檔就可以達成同樣的效果

舉的例子來說
就是大家常常在用的jdbc連線方式就是如此了
透過更換不同的db的jdbc jar就是阿

其實factory di ioc等等
如果實作只有一個,也沒有其他要監控或listener的話
那也不需要spring了
(但通常不太可能真的有那麼單純的環境吧)
所以如果你有proxy的需求(通常交易控制就是了)
那你就需要factory di ioc等等來幫助實現proxy
通常這就是非常客製化的部份
因為每個專案的需求通常都不太一樣
例如交易控制及範圍,權限檢查,登入紀錄,稽核審查,元件監控等等等...
以上這些,都需要proxy來實現(因為這樣比較方便簡單)
然後spring就是你需要的物件框架
然而現在的j2ee也都有支援了 XD



※ 引述《ghost3401 (阿hoho)》之銘言：
: 之前剛接觸完STRUTS2..還沒摸熟
: 馬上就碰到SPRING..
: -------------------------------------
: 教學網站上，基本概念用不同DEVICE存取的例子:
: public interface IDeviceWriter {
:     public void saveToDevice();
: }
: public class FloppyWriter implement IDeviceWriter {
:     public void saveToDevice() {
:         ....
:         // 實際儲存至Floppy的程式碼
:     }
: }
: public class UsbDiskWriter implement IDeviceWriter {
:     public void saveToDevice() {
:         ....
:         // 實際儲存至UsbDisk的程式碼
:     }
: }
: (謝謝梁葛格文章...)
: 在最近接手的專案，使用STRUTS2 的 Action 作為 Controller
: 用 annotaion 及 XML 設定方式注入需要的 Service 及 DAO;
: 我想請教的是:
: 1. 每個Service 和 DAO 都要先有個空介面，再來實作，
: 最後透過注入的方式於Controller使用；這樣做法是以後維護及延展性佳(?)
: 但DAO通常不是寫了就寫了，需要的話就一直在裡面加方法取資料..!?
: 一個DAO用一個介面，CODE中也沒有看到重複用同一個DAO介面的；
: 所以在DAO部分，每個DAO使用一介面實作用意是?
: 2. 呈上..Service部分也是一樣，目前看到的是
: 每一個Service實作一個介面，不重複
: 沒有範例中同是儲存體，但寫入方法不同的情況;
: 所以DI IOC特性在我這個專案中，WEB MVC帶來益處是甚麼?
: 麻煩大家觀念指正，感謝!!

此外ioc對於程式架構非常有幫助
也可以用來整理你的程式碼
所以透過導入spring,然後需要ioc跟di的理由
反向的強迫你的專案成員去整理程式架構
大概最明顯的好處就是
你的程式碼將會少很多
例如以下這種:
if(XX){

}else if(BB){

}else if(CC){

}else{

}
使用ioc跟di的話就會變成

@這邊做di的annotation
private List<DoInterface> dolist;

public void doXXXLsit(){
 for(Dointerface dointer : dolist){
   if(dolist.match()){
        dolist.do();
        return;//這個就看看是要chain還是策略就看看摟
   }
 }
}

@這邊做DI的注入設定,以下省略
public XXDointerface implements Dointerface;
public BBDointerface implements Dointerface;
public CCDointerface implements Dointerface;

由於你的程式碼完成ioc,然後透過di來提供實作
這樣的程式架構是非常具有擴展性,修改性的
當你要擴充dointerface實作的時候,完全不用考慮其他層面
因為相依性僅止於Dointerface這個介面
所以這就是介面的好處

可是如果實作只有一個的話,那介面其實就是跟廢物......

此外你的系統是有一個介面對應一個實作而且no more!!
然後有一大堆的介面的話
(通常就是為了介面而介面,可卻不管其實根本就不需要那麼多的介面!)
其實就代表你的系統程式架構似乎有點不太收斂了
其實規劃介面的目的~就是希望系統能夠有所限制,避免類別的特性導致該類別會不受控制
但是實作中
或許開規格或許方便或許..
然後就會發現一堆的介面就產生了
仔細去看介面的內容其實很多的大同小異
這也是我覺得介面沒有必要的原因,因為結果都一樣
◢▆▅▄▃-崩╰(〒皿〒)╯潰-▃▄▅▆◣
因為整個架構都發散了~有沒有介面其實都無所謂了
所以快去找個好的系統架構人員幫你看看系統吧!!

我自己的習慣是先去整理DAO部分
然後往service logic controller(action)去整理
加油吧

--

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 163.29.29.131
推 PsMonkey:未成年就這麼優是吧？ XD
※ 編輯: swpoker         來自: 163.29.28.131        (09/09 18:04)
※ 編輯: swpoker         來自: 163.29.28.131        (09/09 18:12)
推 ghost3401:吸收中>>
※ 編輯: swpoker         來自: 163.29.28.131        (09/10 17:07)
→ ghost3401:1.小聲問甚麼是對外顯示? 以開發來說不是全部都看得到?
→ ghost3401:2.感恩 各位回的都有解答到我!
→ swpoker:我常幻想自己是某類別，去研究類別的互動！宅吧！
推 PsMonkey:基本上包成物件就是希望讓你可以不用全部看到阿 @_@
→ swpoker:其實他是用人類的眼光去看程式的