1、我們專案中使用spring，主要是使用了其依賴注入，簡單的說是為了類的解耦，以提高復用性。但問題是：
我們在公衛平台中寫的這些類有復用的地方嗎，相反，為此我們引入了一堆第三方的東西，一堆配置檔案，我們的公衛平台貌似沒那複雜喲；
2、為了使用spring,我們定義了一推介面，介面是用於抽象的，用於多型的目的，我看不出我們程式當中有多少多型的東西；既然無多型，為什麼要搞那麼多介面呢
3、也許有人會說，用spring結構層次清晰，spring 工廠很強大，但是，這有更為簡單的方法例如服務定位、單例的使用、**的使用可以加以解決，為什麼要用spring呢
4、可能有人會說，大家約定都這麼做，有個開發約定的問題，我認約定的問題要靠包的命名、類的命名、變數命名規範、注釋、**規範等來加以解決；
5、sping 可以控制類是單例的，但是我們平台專案很多地方沒有加入控制，在某些情況下，我們平台執行存在記憶體溢位的風險；
struts是個mvc結構的東西，
struts提供豐富的jsp 標籤庫： html，bean，logic，template等，這有利於分開表現邏輯和程式邏輯。其初衷是方便美工與開發人員協同工作，在乙個頁面上完成全部設計，但實際情況是頁面幾乎都是由開發人員完成，而且提供的標籤和struts耦合，這對頁面復用可沒啥好處，更何況我們專案貌似也沒用struts2的標籤吧，那這一部分的好處我們用不著；
struts2 的控制器分為數層：
核心控制器：我們的專案只讓它起到乙個分發請求的作用，action還的在struts.xml記錄，把action寫在配置檔案當中，其初衷是action可配置，問題是我們專案有這樣的需求嗎，頁面跳轉的東西也是類似的。
所謂ssh輕量級框架,對於我們這樣的專案而言一點都不輕量級，我們不僅需要維護**，還需要維護繁瑣的xml配置檔案，無配置檔案而能實現的框架功能的東西還是比較容易設計的
我並不是一味的反對使用ssh框架，ssh在我眼裡主要作用是規範開發，我們平台專案，無複雜業務，是對於我們這樣的小團隊而言從技術經濟和可靠性出發完全可以選擇更加簡潔的框架，早日拋棄ssh框架選擇更簡潔的技術在對我們這樣規模的團隊開發是一種比較明智的選擇。
關於專案SSH 框架的一點想法
1 我們專案中使用spring，主要是使用了其依賴注入，簡單的說是為了類的解耦，以提高復用性。但問題是 我們在公衛平台中寫的這些類有復用的地方嗎，相反，為此我們引入了一堆第三方的東西，一堆配置檔案，我們的公衛平台貌似沒那複雜喲 2 為了使用spring,我們定義了一推介面，介面是用於抽象的，用於多型...
關於學習的一點想法
上了十幾年學，才發現自己很多本質的問題從來沒有想過。人類在發展過程中會遇到各種各樣的問題，面對各種各樣的問題，人們提出了各種解決方法。但是如果不用文字記錄下來，讓更多的人看到，實現知識的傳播，那麼未來的人類面對相同的問題就會一臉懵逼，然後花很多重複時間解決乙個解決過的問題。所以人類把各種問題的解決方...
關於CTFT DTFT DFT的一點想法
關於ctft dtft dft dfs等概念的理解一直是模模糊糊 似是而非的，近日忽然就咂摸到了一點滋味，簡單記錄一下，正確性不敢保證。考慮到計算機只能處理時域離散 頻域離散的訊號，因此時域連續或頻域連續的訊號，計算機無法直接處理 這是大前提 因此需要對連續的訊號進行離散處理，這就需要用到衝激串了 ...