其他

    目前國內興起的GIS應用，大都都是二次開發。因為對於做應用來講，二次開發的好處是顯而易見的。    1.方便性    二次開發的技術含量較低，主要要實現的不是GIS本身的技術，而是所有實現的具體的應用，也就是我們常說的業務。在瞭解業務的基礎上，利用GIS平台開發相關的應用軟體就顯的比較方便。   

最近研究了一下Microsoft Enterprise Library的Configuration的原始碼，對其構架有了一個大體的認識，學到了不少的東西，雖然代碼比較簡單，但是它的構架靈活性，可擴充性，可配置性。很值得我學習和借簽。 在日常的工作中，在作某系統應用時，沒有站在構架這個高度上去考慮問題。可能是因為偷懶，或者腦袋不原去考慮那麼多的問題，所以編寫出的代碼非常的死板，在系統需求稍稍變動一點點，往往會導致整個系統代碼的修改。呵呵，這也許就是成長的代價吧。

為懶惰而驕傲                                                                          ——《More Effective C++》讀書筆記之效率        生活中，懶惰常常被認為是貶義的，形容人不求上進。但在編程的時候，“懶惰”卻被認為是一個非常好的習慣。要不Scott Meyers在More Effective C++中談到效率的時候為什麼說“關鍵是要懶惰”呢？   

看完了Configuration的配置提供者，轉換器和中繼資料後，對Configuration有了一個大致的瞭解，接下來Configuration是怎樣通過提供者和轉換器根據中繼資料來產生系統使用者所期望的配置資料類的呢？ConfigurationBuilder!這個類是Configuration最核心的類，顧名思義，它就是建築師，中繼資料是它的藍圖，提供者和轉換器就是它的建築工具，最後建築出形色各異的建築。呵，話歸正傳。來看看下面的類別關係圖吧：從關係圖可以看出，除了Configuration

英文關鍵詞：Constructor Dependency Injection and Unit Testing（為了方便英文搜尋）自從部落格園Team

  最近深入的閱讀了P&P的Cache應用程式塊，收穫頗多。便寫下筆記。以便日後查閱。首先。為什麼會有這個應用程式塊呢？NET FRAMEWORK中不是已經有了Cache這個類嗎？我也是經常用到這個類，以便最佳化程式效能。其實我覺得還是蠻好用的。那麼它有哪些不如意的地方呢？第一:

        前一段時間看了JGTM'2004的用透明代理機制實現簡單AOP的文章後,受益頗多...但是正如他自己在Blog中所說的那樣,使用上述這種方法的局限就是使用的對象必需要從MarshalByRefObject類繼承.由於C#沒有使用多重繼承,所以對於我們自己的程式而言就操作起來不是很方便.這幾天在CodeProject上面發現DynamicProxy的東東,細細看了一下,發現通過這個東東,完全可以取代上述方法,而且對操作的對象沒有必需繼承自MarshalByRefObject的限制.

  第一個MIDP小遊戲          三周前開始接觸J2ME這玩意兒，為的是給My Phone做點東西，應用也好，遊戲也罷，總之學習並進步著的感覺，不錯。        經過看文檔、泡論壇等多種手段，我知道了MIDP為何物：對於程式員來講，它是一個編程平台；我知道了要使自己寫的MIDlet跑起來，需要經過編譯，打包成jar，再通過預檢查，然後才能放到手機中運行。哦，還需要產生一個jad的描述檔案。       

Microsoft Enterprise Library---解讀Cache之設計與分析 Cache應用程式塊的作用與設計在MSDN的文章中已經表述得很清楚了，此篇文章旨在將Cache應用程式塊更深層次的解剖，並描述其類藍圖及主要流程。“麻雀雖小，五髒俱全”，對於Cache這種小的應用程式來講，看上去好像不值得去研究與學習，其實不然，Cache給我很大的啟示，它的構架，設計，及編碼。    1． Cache可以劃分為以下幾個部分：  可以看出，1.1

昨天下午公司項目組的一周總結會上，專案經理說到了群組成員寫注釋的問題，他說到很多程式員都不願寫注釋，項目的首席設計師立即表示反對，我當時感到特別奇怪。寫注釋現在已經公認的了，還有什麼要反對的。下面是設計師反對的意見：如果一個系統中注釋過多，編譯成DLL後會使DLL的尺寸增大，從而影響的系統的效能。。。加註釋可以，但是一定要在注釋前後加入#if debug ;#end debug

正如MSDN對Logging介紹的那樣，幾乎每個企業級應用程式都要求達到的功能—日誌管理功能，即對應用程式的某些特定的行為進行記錄，以便管理員或程式員能瞭解程式運行時的行為特徵，提高他們也應用程式之間的“可互動性”。Logging應用程式塊有著良好的可配置性和擴充性，即在不需要修改代碼的情況下，能通過更改配置來定義日誌的行為，當然，也可以通過實現程式塊所提供的介面集，來擴充日誌的行為。這符合軟體設計所遵循的“開—閉”原則，特別是越處於整個軟體系統底層的程式塊（庫），由於被依賴性非常的強，越需要遵

       在asp中我們可以比較容易的實現伺服器變數和用戶端的互動。那麼在.net中我們怎麼實現呢？       我們知道在asp.net中我們一樣可以在頁面中使用<%=Var%>。那麼，從這一點看來我們將伺服器端值賦值給變數Var。但是這裡有個注意點--我們必須在頁面對應的.cs(或.vb)中先定義這個變數。而且這個變數不能被定義為private型。因為.cs檔案是.aspx檔案的預設基類。如果我們將變數定義為private那麼我們在.aspx中將不能用到這個值。       

       從.NET N 層構架來看，各層當中UI層複用性是最小的，在團隊開發時，商務邏輯層，資料訪問層，資料庫都可以很輕鬆的統一規範起來。但是在開發UI層時，團隊的每個成員都是各做各的，很難做到資源的共用和代碼的重用。     

原址連結：http://msdn.microsoft.com/msdnmag/issues/05/07/DesignPatterns/最近，Microsoft越來越強調設計模式。如果你不熟悉設計模式，那麼你會被這些新的術語和從來沒有看見到的UML圖所淹沒。這次對設計模式的強調，相對於詞彙的變化來講，在方法論上並沒有太多的變換，因為Microsoft .NET Framework base class library

        最新的AspNetForums已經提供下載，但是由於beta版的原因，所以這裡還有一些小問題。最大的就是資料庫安裝的問題（陳銳已提供解決的方法）。        但是，我發現在我的電腦上還有另外一個小問題(我安裝在C:\AspNetForums2)。在我們建立虛擬目錄後，如果我們開啟AspNetForums2\Web下面的AspNetWebForums.sln那麼會出現“c:\AspNetForums2\AspNetWebForums.csproj無法與http://local:

今天發現系統中LIST頁面中分頁有問題，有些記錄顯示不出來，LIST頁面用的是TOP+暫存資料表SQL，錯誤在於： 當點擊INT類型的欄位排序，有些記錄在所有的頁面都找不到，百思不得其解， 把SQL語句摳出來運行發現：對於TOP+數量的用了ORDER BY語句取出來的記錄的順序不一樣，發現 順序不一樣的行是值相同的那幾行，比如： SELECT TOP 10 * FROM TABLE1 ORDER [COUNT]  ASC結果如下：   IDCOUNT13112225646586987

迭代器模式（Iterator Pattern）        許多編程的任務都是操作集合。無論是簡單的對象列表還是複雜的B-Tree集合，我們都需要經常訪問集合裡的元素，我們經常通過一些方法來訪問這些集合中的元素，例如從前到後，從後到前，或者正序或者倒序訪問。          一個最常見的基本方法之一就是將對象列表格儲存體的數組裡，數群組類型已經內建在VB.NET與C#語言裡了，它們都有對數組元素進行枚舉的迴圈結構：在C#裡是Foreach,在VB.NET裡是For

     今天跑上來看了N個BLOG,感觸挺深的,呵呵,總感覺大家的BLOG有很大的比例在分析,解釋,學習別人的東東?為什麼?對,師夷長技嘛,不過老是這樣也挺煩躁的,如果這樣,不管大家的技術怎樣怎樣,這裡只是在DOTNET裡,你會想到什麼新的東西麼?有句話說得好------創新不要只是在技術,而是你的意識!          比如,我就有一個想法:     

所做的項目就要進尾聲，做為開發組的一員，總會根據自己所做的，所寫的總結一些，思考一些，為自己以後的項目開發提供經驗和教訓。 看了聽棠.NET 所寫的關於構架中COMMON層的想法，很有同感，這也是我常常思考的問題：如何使一個項目以最小的代碼量，最大的一致性完成？能不能為以後類似的項目提供現成的類庫？而不是周而復始的重複的寫代碼？能否使系統便於修改，能以最少的時間，最小的工作量完成客戶的需求的變更？這是我所思考的，也是在摸索的。。。。