Harry's Tech World

先前產品自行封裝 Ajax 並實作 Ajax 送出後block UI，當然封裝有他一定的好處，但是萬一今天我不想用封裝的元件時，我又想要block UI時，寫法就會很麻煩。
可能變成會這樣寫：

今天在幫同事解問題的時候，碰到一個明明已經回傳一個新的Model 給前端了，但是資料依然是舊的，原來是ModelState影響了結果。

在幫同仁Code Review 的時候，看到「標準」的IO寫法，如下：

   try
   {
      FileStream fileStream = new FileStream("c://test.txt",FileMode.Create,FileAccess.Write);
      //IO Process...
      fileStream.Close();
   }
   catch (Exception _Exception)
   {
     throw;
   }

就是基本的try catch，然後就是 Release Resource (Dipose)，但其實有更好的寫法，就是使用「using statement」，如下：

今天產品發現NHibernate Session Update 失效了，查了很久發現是我們在Service Layer 的 Aop Transaction 失效了，

導致Load 出來的物件沒有被掛上Proxy ，進一步影響NHibernate 無法監控物件是否有被異動。

最近在做產品的產品，底層是使用NHibernate，Review 時發現同仁在 Update Table 有一些多餘的寫法，

前陣子有一篇文章 [Asp .Net MVC] AjaxHelper 失效了！Why? ，在介紹使用 Unobtrusive Ajax 來讓AjaxHelper 的 Form Submit 正常，

往下開發的時候，發現我們在使用MVC 資料標記(Data Annotations)，每次都得回到後端檢核後才能知道前端傳回來的資料是否符合條件，

才發現原來沒有使用到 Unobtrusive Validate 的機制來做Client 端的資料檢核。

View Model 與 DTO 到底有何不同的時候，想用這篇文章解釋一下差異。

簡單來說View Model 是一個 POCO 物件，一個POCO 物件可以包含以下行為：

1. 保留狀態(State)。
2. 具有行為(資料驗證...)

最重要的就是具有行為，我們在做前端畫面時，很常透過Data Annotation 的方式，來驗證前端傳來的資料是否符合我們的定義，

最近剛好有機會跨部門參與系統架構的討論， 碰到把ViewModel 傳進「商業邏輯層」的現象，

藉此機會把MVC 的系統架構釐清清楚，避免後續再有類似情形的發生，

也會順便探討不傳進去的「好處」有哪些！

公司產品使用Kendo 來製作前端畫面已經一段時間，其中Kendo Grid 更是大量使用，

基於效能與使用性的考量，Grid 的部分還自行客製了「分頁」與「排序」的功能，

因此就自行寫了許多Code 來達成這些目的，當然在一次次的維護與除錯後，

這些Code 變得又臭又長且非常難以維護，每次碰到問題時接手的人都要花很多時間來看這些Code。

最近同事有提出Kendo 本身就有提供「KendoGridRequest」來協助我們完成「分頁」與「排序」的功能。

同事專案上碰到Json字串過長的問題，他使用MVC 內建的序列化方回傳Json 資料

卻出現「使用 JSON JavaScriptSerializer 序列化或還原序列化期間發生錯誤。字串的長度超過在 maxJsonLength 屬性上設定的值。」的錯誤訊息，

改用Json.Net 意外發現，兩者的效能差很多...