來寫寫這一類的日記，記錄下自已的工作內容。 Just FOR FUN。
這個是一個下午的時間與客戶討論，從中也得到些學習，
在筆記內容，分出各個「主戰區」，記下那一段的討論主題及內容。
第一張討論內容：
在昨天，把這段的程式內容寄給客戶後， 客戶也先回了一封EMAIL (個人覺得除了就事外，也有些是就人而論@@)
今天早上有些不順事(AP Service 掛了，無法讓客戶測)，直到下午討論，
這一次的討論，我的心裡是覺得，有些應該是我想他應該認同的或是他所懂的，但他卻有提出質疑？我想，應是多多教育我觀念吧。
主戰區一：
a. 畫出Cache 運作核心，而所謂「代碼全放」或是「只放部份」這是由外部決定的。
b. Cache運作核心：由Key來判斷是否有值，沒值時至「DB」取得該筆資料再放至Cache裡。
c. 這部份，客戶有意見：
1. 若是全放，怎麼會有取不到資料的問題？？
=>這段有和他解釋，Cache核心並不會先假設全放或沒有全放，它就是依它的邏輯運作。
2. 若取不到資料到DB再取，那下次再取不到時，是否也再去DB取，會多一層，這樣不是浪費？。
=>我提出，Cache 的價值不就是這樣嗎？且不該以最糟狀況來否認它存在的優勢的。
主戰區二：
a. 有個CacheTable，裡面資料存異動的資料，藉言batch來更新此資料。
b. 有段認知的誤會，這程式是不會放至Service下的，而是單純的排程或執行檔之類的處理。他誤以為我是要寫在Service下的。(不過，寫在Service下，再讓批次來呼叫，是否也是好？統一管理)
c. 他說了一個觀念， 這DB Table 是「暫時」性的，因別系統異動資料我們不知，才藉由此Table來管理，若未來那些「維護」程式是在我們系統時，直接於異動時，去更新Cache資料即可。
而我的認知，是想由這Table來當統一處理Cache資料的「集散處」。
但想想，若Cache核心提供 異動Function，那直接在程式異動處時，直接更新，也是不錯。
=>結論：接受他 DB Table 的含意概念。
主戰區三：
a. 他要確認我對Web使用Cache及 AP使用Cache 的處理方式認知是否正確？
b. Web / AP 呼叫一樣Reference Service.Interface (Cache Function 描述於此)
差異是在 當找不到資料時，要到DB取時，走的路是不同的。
c. 透過 IoC的方式實作：
1. 這部份，我會參考他的 Unity 的架構方式，把它應用進來。
2. Web 要去實作 CacheProvider Interface ，裡面就是描述，若無資料時，要呼叫Service處理。而AP實作處，就是直接到 DB取資料。
主戰區四：
a. 再次強調，Cache 核心的 架構，也釐清架構是：「Cache底層(AppFabric)」>「Cache核心(就是我要寫的這段)」>「外面應用」
b. 也在這段， 討論到「主戰區二」的CacheTable 及Batch的含意。
=====================================
第二張討論內容：
主戰區一：
a. 這邊我已是在做「總結」，看這一次的討論結果有什麼。
針對它的內容：
「1」：這個是說參數先「假定」它的Key只有「一個」，而不是我當初所想的那麼彈性！
另一個 Tony 藉由 Interface 來規範的概念，我覺得不錯！但被以「不想在DBModel多加額外的Fuction \ 建構式 \ Property」給反對掉。
「2」：這是我記錄，我的Cache Key 是由TableName做存Cache的Key，而TableName就由傳入的Model取得上面的Mapping Attribute來做。
「3」：同上。
「4」：定義一個 Interface ，到時由 Web / AP 來實作取得資料的方式。
主戰區二：
命名，是客戶最「有個人喜好」的地方，我命的，大多都是不他所接受的，所以請他敲定這一塊。
不過，他命名的原則，我也是屬認同，有User要呼叫的就「精簡」，User不會使用的就命「具有含意」的名字(ex:Interface)。
「主戰區三」也是這內容：
a. CacheManager => Cache (裡面的GetCache => Get , )
b. 我這功能也整進去至 Cache Class 裡， 命名是：GetCode (取得代碼) 這個簡易名稱。
c. 他說：不用 SetCode ，因為 User 用不到！就不要定義在這 。(這部份...不太懂，等之後遇到時再看他要寫在那)
d. Interface ：ICodeDataProvider
主戰區三：
是主戰區二的延伸。
主戰區四：
這討論到 AppFabric 是否可以放[client」的機制在，
但若這樣，豈不是失去AppFabric 的用意？？？
這部份，也要看，到 Cache Server 取資料時，損失效能的比例有多大而訂。
-----------------------
這樣的討論，我的論述較弱的部份是：較沒有掌握技術的精確文字，只是概念，但卻「不精確」。
這個是一個下午的時間與客戶討論，從中也得到些學習，
在筆記內容，分出各個「主戰區」，記下那一段的討論主題及內容。
第一張討論內容：
在昨天，把這段的程式內容寄給客戶後， 客戶也先回了一封EMAIL (個人覺得除了就事外，也有些是就人而論@@)
今天早上有些不順事(AP Service 掛了，無法讓客戶測)，直到下午討論，
這一次的討論，我的心裡是覺得，有些應該是我想他應該認同的或是他所懂的，但他卻有提出質疑？我想，應是多多教育我觀念吧。
主戰區一：
a. 畫出Cache 運作核心，而所謂「代碼全放」或是「只放部份」這是由外部決定的。
b. Cache運作核心：由Key來判斷是否有值，沒值時至「DB」取得該筆資料再放至Cache裡。
c. 這部份，客戶有意見：
1. 若是全放，怎麼會有取不到資料的問題？？
=>這段有和他解釋，Cache核心並不會先假設全放或沒有全放，它就是依它的邏輯運作。
2. 若取不到資料到DB再取，那下次再取不到時，是否也再去DB取，會多一層，這樣不是浪費？。
=>我提出，Cache 的價值不就是這樣嗎？且不該以最糟狀況來否認它存在的優勢的。
主戰區二：
a. 有個CacheTable，裡面資料存異動的資料，藉言batch來更新此資料。
b. 有段認知的誤會，這程式是不會放至Service下的，而是單純的排程或執行檔之類的處理。他誤以為我是要寫在Service下的。(不過，寫在Service下，再讓批次來呼叫，是否也是好？統一管理)
c. 他說了一個觀念， 這DB Table 是「暫時」性的，因別系統異動資料我們不知，才藉由此Table來管理，若未來那些「維護」程式是在我們系統時，直接於異動時，去更新Cache資料即可。
而我的認知，是想由這Table來當統一處理Cache資料的「集散處」。
但想想，若Cache核心提供 異動Function，那直接在程式異動處時，直接更新，也是不錯。
=>結論：接受他 DB Table 的含意概念。
主戰區三：
a. 他要確認我對Web使用Cache及 AP使用Cache 的處理方式認知是否正確？
b. Web / AP 呼叫一樣Reference Service.Interface (Cache Function 描述於此)
差異是在 當找不到資料時，要到DB取時，走的路是不同的。
c. 透過 IoC的方式實作：
1. 這部份，我會參考他的 Unity 的架構方式，把它應用進來。
2. Web 要去實作 CacheProvider Interface ，裡面就是描述，若無資料時，要呼叫Service處理。而AP實作處，就是直接到 DB取資料。
主戰區四：
a. 再次強調，Cache 核心的 架構，也釐清架構是：「Cache底層(AppFabric)」>「Cache核心(就是我要寫的這段)」>「外面應用」
b. 也在這段， 討論到「主戰區二」的CacheTable 及Batch的含意。
=====================================
第二張討論內容：
主戰區一：
a. 這邊我已是在做「總結」，看這一次的討論結果有什麼。
針對它的內容：
「1」：這個是說參數先「假定」它的Key只有「一個」，而不是我當初所想的那麼彈性！
另一個 Tony 藉由 Interface 來規範的概念，我覺得不錯！但被以「不想在DBModel多加額外的Fuction \ 建構式 \ Property」給反對掉。
「2」：這是我記錄，我的Cache Key 是由TableName做存Cache的Key，而TableName就由傳入的Model取得上面的Mapping Attribute來做。
「3」：同上。
「4」：定義一個 Interface ，到時由 Web / AP 來實作取得資料的方式。
主戰區二：
命名，是客戶最「有個人喜好」的地方，我命的，大多都是不他所接受的，所以請他敲定這一塊。
不過，他命名的原則，我也是屬認同，有User要呼叫的就「精簡」，User不會使用的就命「具有含意」的名字(ex:Interface)。
「主戰區三」也是這內容：
a. CacheManager => Cache (裡面的GetCache => Get , )
b. 我這功能也整進去至 Cache Class 裡， 命名是：GetCode (取得代碼) 這個簡易名稱。
c. 他說：不用 SetCode ，因為 User 用不到！就不要定義在這 。(這部份...不太懂，等之後遇到時再看他要寫在那)
d. Interface ：ICodeDataProvider
主戰區三：
是主戰區二的延伸。
主戰區四：
這討論到 AppFabric 是否可以放[client」的機制在，
但若這樣，豈不是失去AppFabric 的用意？？？
這部份，也要看，到 Cache Server 取資料時，損失效能的比例有多大而訂。
-----------------------
這樣的討論，我的論述較弱的部份是：較沒有掌握技術的精確文字，只是概念，但卻「不精確」。
0 意見 :
張貼留言