其他

對於送耦合的引用，有一下四種選項。1.MSMQ從windows nt 開始微軟就開始提供msmq 的支援，一直到現在的3.0，主要提供一下幾個特性的支援。 可靠的訊息傳遞，類似mail 系統，有離線支援可設定訊息的優先順序，Label的各種額外的標示事務支援通過DC,IC的靈活應用，有好的縮放性對於用戶端，要求必須是windows 系統，從windowsce 到windows .net 2003 都作支援。可以通過連接器跟其他的非微軟技術整合.NET 有一個專門的封裝

Biztalk 可以做EAI，也可以做B2B。 做EAI的話，是企業內部的一個資訊Hub或者匯流排。如果做B2B的話，則相當於企業對外的一個Gateway。不同的partner有不同的平台或者標準以及設定。所以biztalk除了做整合之外，還要去管理這些契約和中繼資料。假定企業A使用EDI來跟不同的上下遊做整合和資訊交換。EDI經常會問幾個問題？ 這家企業使用的是那個版本？EDI有好多版本。對應到Biztalk就是我收到這家企業的EDI之後，該用哪個Schema來解釋

Expression blend 2.5 是目前的最新版本用來支援WPF和Silverlight Beta2 的開發。一般我們可視化的拖放和設計介面和效果。有時候如果你要人為的編輯一下Xaml的話發現沒有智能提示非常不方便。有些屬性很長的話，很難記住。由於Expression本省是個WPF程式， 當然也是標準的.net程式。所以擴充其實很容易，Expressoin提供了一個IAddIn介面，你只要實現該介面就可以了。

今天早上6：00就起床了，6：30準時出發，因為到LA的路非常的堵車。第一個Session是KeyNote，是Ray Ozzie 大概的介紹了一些微軟的下一代策略和方向，然後幾個VP帶頭示範了一些應用。Ray

 這一篇先從整體上講述一下系統的各個模組，理一理系統的面目的形成過程。首先明確的一點是這將是一個CS的系統，系統有離線的要求，而且更重要的是用戶端要訪問硬體裝置，而且用戶端的顯示重新整理是要達到准即時要求的，這些東西用BS的架構是難以實現的。開發環境先確定下來就是VS.NET 2003、SQLServer 2000。當時VS2005及SQLServer 2005雖然已經越來越多的被使用，的確也是有比較多迷人的特性，但對於非BS的開發來講，於我看來優勢不明顯。而且相對來講.Net

 前面幾篇基本把簽到終端的各個模組描述了一下，至此簽到終端的主程式要做的事情相對就簡單了許多，但實際實現中還是化了不少的精力，跟UI相關的東西做些來總是很費力的。不過相對來講技術含量就低了，何況當時也是沒有很深思熟慮（即使是UI的呈現本可以做得更好些的），所以這裡也沒有什麼好談的了。需要進一步提煉的地方以後專門開篇講，接下來就開始著眼於管控端。 簽到終端的模組劃分比較著重於技術架構，那管控端的模組劃分就側重於業務功能了。管控端是我們相對比較熟悉的程式，有各式各樣的表單，有菜單、工具列、狀態列。因

Is there such a thing as too many blogs? We've certainly pushed the limit in the past couple of days, and a few folks have pointed out that some of the entries are dropping off the view, and may be getting missed. Here's a list of all the blogs in

今天去參加了兩天的關於ILM V2 的培訓，大概總結一下相對於ILM 2007 有哪些新的特性。ILM 是什嗎？顧名思義是一個身份管理軟體。當一個人進入一個企業之後，他會有不同的身份。比如AD帳號是他的一個身份，ERP 系統的帳號是他的一個身份，

 本要接上一篇開始講管控端程式的菜單與工具列的載入，但發現還是先要講一下整個管控端的表單組織，否則會無法理解菜單事件為何要那麼寫。多表單組織很經典的模型就是MDI了，但MDI在表單最大化、最小化、還原一些動作之後，表單會亂掉，很亂七八糟。現在的程式很少有用那種原始的MDI來作介面的了，至少我不會去用，實在是難看。但開發工具在這裡也是沒有長進，如果我們直接用IDE只能產生那種原始的MDI表單。只能另想辦法，其實也沒多想，因為以前（一年多前）曾經為同學做過一個DEMO，當時也是基於難看的MDI，在S

 這一篇還沒準備進入實質性的階段，先插段事關整個系統的異常處理部分。最基本的原則當然是所有有可能影響到系統正常啟動並執行異常都要Catch，並作記錄，所謂最基本的原則當然只能是到具體實現的階段把握了。但總有百密一疏，掛萬漏一的時候，對於這些漏網之魚必須在Application.ThreadException與AppDomain.CurrentDomain.UnhandledException事件中根據情況處理掉。對於已經冒到上述二個事件中的異常，不但要作記錄，還要出個Error形式的對話方塊提醒

 經過上一篇定義的兩個介面，菜單與工具列基本上符合了Command模式的樣子，接下來應該可以在系統中載入了。但理論上照著模式是一回事，實實在在的寫代碼又是另一回事。我們很遺憾地發現ToolBarButton這個類根本沒有單擊事件，甚至跟UI有關的事件都沒有一個，因為它根本就不是從Control繼承的，而是從Component繼承的。工具列按鈕單擊是從工具列ToolBar的ButtonClick事件來的，就是說如果你要掛一段單擊工具列上單個按鈕時發生動作的代碼得掛在ToolBar的事件上，除些之外

 先來個Delphi的：The CodeDOM and the Delphi for .NET IDE  通過OTA在IDE裡瀏覽CodeDOM。作者是Borland的工程師(他的BLOG) 在A Look At CodeDOM這篇BLOG裡有很不錯的連結，品質很高的。 MSDN http://msdn.microsoft.com/netframework/programming/bcl/上有個叫CodeDOM Test Suite的，This suite is used to test

今天碰到了個非常奇怪的問題，而且無法重現。在一個類構造的時候從 xml 檔案還原序列化一個對象。一般情況下都是好，極少數情況下會出現一下問題。System.Runtime.InteropServices.ExternalException: Timed out waiting for a program to execute. The command being executed was "c:\windows\microsoft.net\framework\v1.1.4322\csc.exe"

 這一篇其實沒什麼可講的，只提一下跟用戶端不太一樣的一些地方。服務端跟用戶端最大的區別是它面對的不是單單一個串連，而是有一些個串連。對於接收與發送來講它是要具體到accept進來的每一個串連的，所以這裡有一個SocketStateObject參數會貫穿始終，這個參數主要就是放對應用戶端的Socket串連及一些狀態變數，在accept進來一個串連後即建立一個這個對象。       public void Listen(int port)       {                    

 上周參加俱樂部活動，最後有個話題――Developer的英雄時代是否已經結束？因為我的論述角度一般是不太非常的，而且總體來講比較的龐大，非三言兩語所能讓人明白，加之本身對此類問題就有點迷迷糊糊，只是隱約從某個角度來看感覺上的一種思索，很多地方不是很成熟。所以當時沒有與大家交流，今日特寫此文論述之。 先開門見山地擺出我的觀點，我認為英雄時代基本已經結束，但英雄的需求並沒有減弱，而且英雄也不會消亡。首先要明確的一點是“英雄”與“英雄時代”的區別，“英雄”是一個個體的概念；而“英雄時代”是一個群體的

  企業庫系列講座（5）：日誌和儀錶盤管理應用程式塊活動日期： 2005-06-17 14:30 -- 16:00 主 講： 曹嚴明________________________________________Q： 關於效能方面的問題，每次寫日誌是否都要讀取日誌設定檔？A: 

    因為DELPHI根深蒂固的緣故，以前看到關於"is"、"as"的資料總是一略而過，總以為它與DELPHI裡是一樣的東西，因為在.NET裡與DELPHI一樣的東西比較的多。    直到昨天看《.NET架構程式設計》才發現原來兩者之間還是有區別的，這個區別直接直接導致了.NET與DELPHI在關於類型轉換上的一些建議寫法。    在DELHI下（代碼亂寫的，手邊沒有DELPHI），type   A = class(tobject);   B = class(A);var   instA:A;

 現在開始進入正題，先簡略地描述一下整個系統的功能，主要為下面我的一些設計作一下鋪墊。簽到系統分前台顯示與後台管理控制二大部分。前台根據硬體裝置讀到的資訊，顯示當前簽到者的資訊，並分類別更新本機已簽到的人數及已簽到總人數。與此同時，顯示當前的網路連接狀態等等。這個是準系統，附屬功能後面講。後台管理著簽到系統的資料庫，對資料表的一些基本增、刪、改、查詢操作是必不可少的，列印功能當然也是逃不了的。最重要一塊當然就是對於簽到過程的管理控制，何時開始、何時停止等等，然後就是半即時的顯示當前簽到人數，顯示

 資料訪問是所有要與資料庫打交道的系統的最基礎模組，也是在當今開發領域中提供現成解決方案最多的。其中一方面當然是各位開發人員的習慣性思維，幾乎每一位有追求的程式員都不會寫出令自己搖頭的代碼，總是力求使系統的實現接近於自己的“理想”，而資料訪問由於資料庫的多樣性及資料庫SQL文法與現今流行的OO思想不適配，給予了程式員們以很大的發揮空間，所以造就了此領域的“百花齊放”；另一方面則是世界事物的複雜性，使各式各樣的解決方案好像都無法勝任，所以“輪子”就越造越多。鑒於項目的特性，表不會很多，但系統對效能

 實現資料同步的正規做法是用SQL-Server的複製功能，但複製在這裡顯得有點小題大做。從一開始在考慮用戶端資料庫時鑒於資料量的大小及用戶端的其他需求，就決定為用MSDE，在每一個簽到終端安裝一個SQL-Server無疑是很浪費的。考慮到為了系統以後有更廣的適用性，使用綁定資料庫平台的技術也不是一種很好的選擇。更為重要的是在系統中，資料同步壓力並不是很大，情況也不複雜，需要動態更新的就一張表，就固定的那幾列，並發衝突的策略也很簡單，在可預見的時間內實現系統勝任的資料同步功能是可以做到的。最終實