其他

軟體設計首先要整理使用者的業務模型，然後以此為參照，結合環境條件，建立軟體系統模型。在這個過程中，很重要的一點是：要剔除軟體模型中多餘的概念。哪些是“多餘的概念”呢？如果一個概念是從使用者的業務模型中無法直接觀察到的，而是設計者推想出來的，那麼這個概念就是多餘的概念。我們想象一個鐵路公司，經營著ABCD四個城市之間的路線。這幾個城市的位置如下：鐵路公司的老闆想做一個售票系統，他找到一家軟體公司。假設我就在這個軟體公司工作，擔任這個項目的負責人。鐵路公司的老闆這麼對我說：從A到B的票價是50元，從

 在上一篇裡面，我們初步瞭解了OO設計，OO設計的最獨特之處在於他看待需求的方式。用這樣的方式，我們不需要急於確定軟體需要實現哪些流程、設計哪些功能點、製作哪些畫面，而是要關注需求中一些更加基本的概念。首先根據這些概念開發出一些零件，然後把這些零件組裝起來實現需要的功能。用這樣的方式，我們不需要一開始就去知道所有的業務需求，只需要知道一些比較重要的需求，就可以開始開發了。這樣開發出來的程式不僅可以實現當前的需要，同時也是一個業務開發的平台，在這個平台上可以不斷的開發新的功能。這種設計思想有很多實

      在ESFramework 4.0 快速上手 －－

      在之前版本的Rapid引擎中，是沒有提供用戶端登陸驗證的機制的，如果要驗證使用者的帳號密碼資訊，我們只有自己手動通過自訂資訊來實現。在2011.04.25發布的新版本中，用戶端Rapid引擎，則內建了在初始化時驗證使用者的帳號密碼的功能，這使得登入驗證變得更加簡單。 一. ESPlus.Application.Basic 空間的支援      為了實現驗證使用者帳號密碼的功能，ESPlus.Application.Basic

引用 在The C++ Programming Language 3rd (Bjarne Stroustrup, 1997)裡:第9頁:Objects of some user-defined types contain type information.Suchobjects can be used conveniently and safely in contexts in which theirtype cannot be deter-mined at compile time.

　　在分布式通訊系統中，網路傳遞的是二進位流，而記憶體中是我們基於物件模型構建的各種各樣的對象，當我們需要將一個對象通過網路傳遞給另一個節點時，首先需要將其序列化為位元組流，然後通過網路發送給目標節點，目標節點接收後，再還原序列化為對象執行個體。在ESFramework體系中，也是遵循同樣的規則。      ESFramework稱這些需要經過網路傳遞的對象稱之為協議類（Contract），協議類通常只是一個簡單的資料結構封裝，用於儲存狀態的一個啞類（不包含任何方法，從object繼承的除外），

    我們的一個C#項目需要調用C++的dll，通過Pinvoke進行方法調用。其中的一個方法及其參數的定義是這樣的：    [StructLayoutAttribute    (LayoutKind.Sequential)]    public struct xvid_gbl_info_t            {       

　　在ESFramework架構中基於TCP的服務端引擎（當然也包括Rapid引擎）都採用了這樣一條規則：預設情況下，用戶端與伺服器成功建立TCP串連以後，服務端會從用戶端發過來的第一條訊息中取出訊息頭的UserID屬性的值，並將其與對應的TCP串連綁定起來。這樣，服務端就知道每一個TCP串連所對應的使用者UserID，而當我們要求服務端向某個用戶端發送訊息時，服務端就知道通過哪個TCP串連進行發送了。TCP串連與UserID是一一對應的，一個TCP串連只能對應一個UserID，同樣的，一個Us

文章目錄 3.ICustomzieHandler  距離ESPlus 2.0發布已經有半年的時間了，在這半年多的時間中，有數十家公司在他們的項目或產品中正式使用了ESFramework 4.0，並根據實際的使用狀況，給我們反饋了很多有益的建議。基於這些建議和ESFramework的長期發展規劃，今天，我們推出了ESPlus 3.0

      （本文所介紹的新功能位於2011.04.18發布的最新版本中，此次版本變更請參見ESFramework 4.0 版本升級說明（持續更新））     

      在ESFramework 4.0 進階（02）－－ 核心：訊息處理的骨架流程一文中我們介紹的ESFramework提供的訊息處理的骨架流程，假設我們有這樣的需求，我們需要在網關級訊息監控器處放置兩個監控器，一個用於對收到的訊息進行特殊的驗證，另一個用於檢查重複的訊息。咋一看，可能覺得骨架流程做不到這一點，因為它只為網關級監控器預留了一個位置，沒有辦法將兩個網關級監控器掛接到這一個位置上。     

剛開始幹這一行的時候，對代碼的複用有很高的熱情。那時候總是希望自己寫出的function、class、模組都是可以複用的，能夠優美的解決所有問題。但是往往事於願違，設計的變更、需求的變更、種種沒有預料的情況最終把自己的代碼摧毀的面目全非。有時一個簡單的function會出現各種不同的版本，SendMessage、SendMessage2、SendMessageEx……在注釋中說明其間微妙的區別。複用的計劃最終破產。經曆打擊後，又走向另一個極端：使用copy-paste解決問題。不在乎代碼的複用性

      “明者保身，但求無過”，如何保身呢？       其實最好的辦法是讓自己保持神秘，盡量少的公開自己的資訊，使民無知。       好的軟體設計追求的就是這種境界。       這裡的“民”指得就是“客戶”。盡量少的公開介面，給客戶一個“瘦”介面，使客戶不知道具體是如何操作的，這樣於人於己都是有好處的。       我還是用排序演算法的例子。我們的目標是把排序演算法通過動態庫的形式提供給使用者。              

　　本文我們將介紹使用ESFramework的Rapid引擎開發的一個最簡單的Demo，該Demo是一個簡單的聊天系統，並示範了以下功能：（1）用戶端使用者上下線時，通知其他線上使用者。（2）當用戶端與服務端網路斷開時，進行自動重連，當網路恢複後，重連成功。（3）所有線上使用者之間可以進行文字交談。（4）訊息同步調用。（5）重登陸模式。當同名的使用者登陸時，會把前面的使用者擠掉。 一.服務端    

    相信有不少人抱怨DOT.NET1.1中的WinForm庫的某些缺陷，曾有人譏笑System.Windows.Forms下面的東西是微軟請高中生寫的，當然這話有些誇張了。但經過筆者的自己的實踐，覺得標準WinForm庫有些地方確實比較弱。   

　　在編碼的時候，我們經常預訂某個事件來處理它，但很少取消事件的預訂，這種做法可能導致程式在運行時出現一些異常。     

      當我們把基於.NET 2.0開發的網路用戶端程式部署到windows 7 家庭普通版上啟動時，報出了“配置系統未能初始化”的異常，在另外一些windows 7 家庭普通版的機器上則報出“應用程式無法啟動，因為應用程式的並行配置不正確 ”的異常。奇怪，以前未用過windows 7 家庭普通版，也從未碰到過類似的問題。      根據異常的提示，我們查看了windows事件記錄，日誌中說xml設定檔的第三行有語法錯誤。我們用戶端的設定檔App.Config相當簡單：<?xml

先重複一下問題：以學生和老師為例public class Student{ string name; Teacher teacher;}public class Teacher{ string name; List<Student> students=new

    由於最近有了寶寶，導致夜裡寫文章的時間越來越短，而白天又忙於開發。沒辦法，只有擠時間去寫東西了。前些天在園子裡看到了這篇文章，http://www.cnblogs.com/Yahong111/archive/2007/07/18/822946.html，對裡面寫的內容瀏覽了一下，這裡首先對作者的實踐精神表示讚賞。我這裡只是從別的角度闡述一下AbstractFactory在這種應用情境下的發展，內容不多，希望大家見諒。    1. DbService