因為檢視層（客戶端）的內容較多，且比較瑣碎，所以先來介紹一下服務層的設計。服務層的基本思想就是可程式設計地依賴注入方式。
現在在服務層次流行使用 spring，一種非常優秀的依賴注入方式。greentea 不是取代或者否定 spring 的設計（坦率地說，也沒有此能力），只是想使開發更簡單。spring 的想法很好，但在 ssh 框架中使用得有點過度，正所謂「手裡有把錘子，看什麼都是釘子」。一般來說，完成乙個普通的功能，spring 需要乙個介面、乙個實現類和配置檔案裡的一條記錄（很久沒有使用 spring 了，現在還是這樣麼？）。這體現了介面和實現分離的實現，很好，但是這種做法真地在實際中發揮作用了麼？在我做過的專案中，我發現 95% 的實現類沒有更換過，換句話說，95% 的介面是沒起到應有作用，反倒是增加了開發的累贅。
面向介面程式設計的思想沒問題，但是需要考慮他是否能起到實際的效用。工程技術是一種權衡，是利與弊的取捨，所以沒有最完美，只有最優的解決方案。spring 最初的想法是想對 ejb 的開發進行簡化，但是我感覺還不夠簡化。因此，我在服務層這個地方採用了「程式設計式」的方式來完成大多數依賴注入的問題。當然，你也可以在這個層次採用spring，只不過是將greentea 的 service 層退化成 struts（老版本）的action而已，也未嘗不可。
閒言少敘，來介紹greentea 的服務層的想法，實現很簡單，類圖如下：
processo***ctory 是乙個處理器工廠，其作用就是生成或者建立乙個新的processor 例項（當然也可以使用物件池）。需要注意的是：在應用的整個生命週期中只有乙個例項，因此不是執行緒安全的，在使用需要注意。乙個應用可能需要多個處理器工廠，可在配置檔案中直接新增。
processor 是真正幹活的類，負責給service 注入其需要的資訊。不同的service 可能需要不同的資訊，因此 processor 需要能識別service（如：service需要實現特定的介面）。processor 方法包括了 serivce 方法呼叫的整個生命週期，因此可以對提供給service的資源資訊進行完全的控制。
service 不需多言，即業務邏輯。
上面說得稍微有些抽象，給出乙個具體的實現即可以很清楚的了解其結構。這個實現以jpa實現注入為例，僅供參考，如果需要在工作中使用還需調整和健壯。
首先來看處理器工廠類。
public class jpaprocesso***ctory implements processo***ctory
public synchronized processor createprocessor(class serviceclass)
return null;}
public void ondestroy() }
再來看一下「processor」，也很簡單，由他來完成資訊的注入，已經方法呼叫時生命週期的所有一切。
public class jpaprocessor implements processor
public void oncreate(class serviceclass, session session, context context)
public object onbefore(object service, method method, object params)
public void onafter(object service, object ret)
public void onfinally()
public void onthrowable(throwable t) }
接下來是「jpaaware」，其主要用來識別類是不是需要使用jpa 進行持久化，並注入所需的「實體管理器」。
public inte***ce jpaaware
最後我們再來實現類。
public class userservice implements iservice， jpaaware
public void setentitymanager(entitymanager entitymanager)
public entitymanager getentitymanager() }
從上述**中可以看出，在編寫業務邏輯時，程式設計師不需要關心怎麼得到實體管理器，怎樣控制事務，怎樣關閉工廠，這些事情都是「processor」統一進行處理的。
在實際使用當中，可以將最常用介面及其基本實現抽象到乙個abstractservice裡面，那樣**可以做到驚人的簡潔。如果我們希望使用 spring，完全可以實現照貓畫虎地實現乙個 spring 的 processor。
開發簡單，雖然開發「processor」稍微多了一點內容，但是只在專案初期使用，在開發業務邏輯時應該已經非常簡單明瞭。
無需配置，減少了不必要耦合點。
擺脫對容器的依賴，使開發和單元測試更加簡單。另外，解除了這層耦合關係，更有利於服務的重用。
如果我們確實需要乙個介面，以便在專案中隨時可替換，greentea 也提供了兩種方式：配置和約定。
配置，顧名思義，greentea 將在配置檔案中查詢介面和實現的對照關係。在配置中新增如下**即可：
注意：aservice 也可以是乙個具體類，即：不侷限於介面與實現的關係，也可以是父類與子類的關係。
約定是指通過隱含的方式來確定這種對照關係。比如： com.xx.yy.aservice是乙個介面或者抽象類，框架將嘗試查詢「com.xx.yy.aserviceimpl」作為其實現類。
系統已經提供了幾種基本實現，以資參考。 名稱
說明ipopersistenceprocessor
greentea 自帶的乙個簡化版的 o/r 對映機制。
injectorprocessor
當需要在服務中呼叫另外乙個服務時，最好使用這種服務注入方式，以保證呼叫方法在乙個事務之內。
sessionprocessor
為服務提供了session的相關資訊。
fileserviceprocessor
為服務提供了統一的檔案處理介面。我在工作中經常遇到的乙個問題是有的程式設計師在使用檔案之後忘記關閉，造成記憶體洩漏，導致了系統的不穩定。使用此介面可以在一定程度上減少此類問題的發生。
一切都是為了簡潔，最大化的減少耦合點。
殺雞用牛刀會有什麼後果呢？
雖然重點，多花了些力氣，但是和用殺雞的刀的效果是一樣的；
雞雖然殺了，但也傷了自己的手；
雞雖然殺了，但是多砍掉了一條腿；
在你掄起厚重的牛刀時散了腰，還讓雞給跑了。
運輸層簡介
封裝和解封 復用和分用 流量控制 差錯控制 運輸層位於網路層和應用層之間，運輸層負責向應用層提供服務，同時它接受來自網路層的服務。運輸層協議主要負責程序到程序間的通訊。程序可以理解未是使用了運輸層服務的應用層實體。比如nginx程序，mysql程序等，都需要把資料傳給運輸層，由運輸層負責把資料報傳輸...
微服務系列 nacos簡介和安裝部署
四 採用mysql持久化 五 開啟許可權認證 總結註冊中心和配置中心應該算是微服務中的標配了。而nacos作為由阿里開源一款非常優秀的產品，成功將兩者結合起來，可以讓開發者將更多的精力投入到業務功能的開發中。1.服務發現與服務健康檢查 nacos使服務更容易註冊自己並通過dns或http介面發現其他...
WebRTC 系列 簡介
webrtc除了是一套api標準，也是google的乙個對webrtc標準api的實現 我們主要討論的是google的webrtc的network i o模組。整體架構 rtp協議棧 real time protocol p2p ice stun turn 用來實現點對點傳輸 架構 這裡主要列出網路...