為什麼要用
businessfascade
層，以前在做
5層架構的程式時，寫出的**中
businessrule
類中的方法與
businessfascade
中的方法是一一對應的。雖然理論上知道
businessfascade
只是乙個
proxy
的作用，但是並沒有體會到它的妙處，今天看到《分布模式》一章，有點豁然開朗了。
在物件導向模型中，經常有很多規模較小的物件，他們有較小的方法。這樣就提供了很多機會來控制和替換某些行為，還可以用良好的命名是應用程式更容易理解。然而，這種小粒度動作將導致大量物件間的互動，而且這些互動通常需要很多的方法呼叫。
在乙個單一的位址空間內，小粒度的互動工作的很好，但是當你在兩個程序之間作呼叫時，這種良好的狀態就不存在了。遠端呼叫的開銷很大，任何物件可能被作為遠端物件使用時，經常需要乙個粗粒度的介面來減少完成某些任務所需要的呼叫次數。
[gang of four]
提出了遠端外觀的概念，就是乙個粗粒度的外觀。所有細粒度物件都沒有遠端介面，並且遠端外觀不包含領域邏輯。遠端外觀所要完成的工作就是把細粒度的方法轉換到低層的細粒度的方法上。如果對應到微軟
duwamish
的例子，就是
businesssystem
層，或者叫做
businessfascade
層。遠端外觀的設計都是基於特定客戶的需要
，大部分的需要都是希望通過使用者介面來**和更新資訊。外觀的設計目的就是要使外部使用者的使用簡單化，而不是為了簡化內部的邏輯。
遠端外觀有有狀態和無狀態之分。無狀態的遠端外觀可以組成池，這樣就可以提高資源的利用率和效率，尤其是在
b
2c
的情況下。當使用有狀態的遠端外觀時，遠端外觀必須維持每個狀態，這可以通過使用客戶端會話狀態，資料庫會話狀態或者伺服器會話狀態來完成。如果使用伺服器會話狀態，可能導致效能問題，尤其是在有成千上萬的使用者同時訪問時。
遠端外觀帶來的
2個好處：1
、可以增加安全檢查
2、提供事務控制。
對於遠端外觀，最大的錯誤就是把領域邏輯放在其中，「遠端外觀沒有任何領域邏輯」
基於上下文的細粒度識別方案
因為之前我針對vgg16 fine tune訓練了乙個人頭分類器，效果較好，所以最主要的特徵提取工作就可以交給預訓練的vgg16來做了。其實我們在做細粒度分類的時候，如果針對整幅影象分類的話，在不同縮小過程中，會忽略掉很多細節，尤其是池化這個過程，但是如果不池化的話，超大的參數量和不夠深的網路是無法...
shiro細粒度許可權控制以及開發中碰到的bug
spring aop 預設動態 方式為jdk 在進行shiro細粒度許可權控制 即控制方法 時，要將動態 方式改為cglib的 因為cglib產生的動態 物件與原物件是繼承關係，這樣寫在原物件上的註解在動態 物件上才會有效 而預設的jdk動態 產生的 物件與原物件實現同乙個介面，類似於兄弟關係，所以...
引入注意力機制的細粒度實體分類
這篇 來自ucl自然語言處理實驗室，發表於2016年。細粒度實體分類是在構建知識圖譜過程中非常重要的內容，關於實體分類相關的文獻也比較多，也有不少分類方法，但是我們如何在非結構化的文字中確定出乙個我們想要的細粒度實體，並把它分入相應的大類中去呢？舉個例子，掘金勝森林狼，約基奇準三雙助球隊贏下爭八關鍵...