恩 其实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 ※ 编辑: swpoker 来自: 163.29.28.131 (09/09 18:04) ※ 编辑: swpoker 来自: 163.29.28.131 (09/09 18:12) ※ 编辑: swpoker 来自: 163.29.28.131 (09/10 17:07)