其他

Reporting Service 是Microsoft提供的整合在Microsoft SQL Server中的一款報表開發工具。由於一直使用SQL Server 2000，所以Reporting Service 2000也就是理所當然的選擇。而Reporting Service 2000是Reporting

最近程式裡發現一個問題，在列表裡快顯功能表(ContextMenuStrip)，並選擇某一項後，菜單一直顯示，並且一直等待菜單事件處理的完成，嚴重的是，有時候，即便功能表項目的事件完成了，菜單仍然不會自動關掉。切換程式後，菜單仍然顯示著，只有回到應用程式介面，再次用滑鼠點一下菜單所屬於的列表，菜單才消失掉。我把出現該問題的代碼寫法貼出來：//公用部分//declarationprivate ContextMenuStrip contextMenuStrip

上天一個同事問，如何做到對資料庫訪問層（DataAccess）的可替換？我是反對憑空創造一種架構的，我提倡任何架構都基於現實的系統需求。但是作為一個思考，又不能有任何藩籬。其實在OO已經深入人心的今天，很多人做架構還是基於資料庫存取的思路，結果所有業務層全是對錶的CRUD的操作，商務邏輯的複雜性已經溶解到強大的資料庫建模之中。顯然這種基於資料庫結構描述的思路，是不利於OO思路的推廣的。我們不得不承認在很多應用中，這種基於資料庫的架構是完全沒有問題的，但是在解析需求時就做資料庫建模，這種習慣在構建

避免失敗的最好方法是不斷的失敗，確切的說應該是，避免產品上線後出現問題的最好方法是，在產品上線前，不斷的讓它出問題。 在現實中有消防演習，軍事演習等等，這都是在出現問題，或者出現緊急情況時的真實類比。對於我們的軟體產品來講，這種“演習”是很容易實現的。與一直很火的持續整合、持續部署一樣，持續測試甚至持續失敗的思路也是一樣的，通過平時高頻率的操作，爭取在最短時間內發現各種可能的問題，從而來規避各種可能出現的緊急問題。 Netflix公司推出了一款叫做Chaos

重構的原因，在於需求的變化。需求沒有變化，也就沒有必要瞎折騰來重構，除非你真很蛋疼。 需求變化有兩種原因:一，是真的變化了。二，對需求的認識深化了。舊的需求，轉化到新的需求，設計就要跟著變化。當然也不是所有情況都需要大變動，很多需求變化，沒有涉及到“筋骨”，就可以保持設計的骨架，而添加新的內容。 一個優秀的設計，應該精良預示到這種簡單的需求變化。如果真的要改變，那哪些設計會比較容易更改呢？

許可權設計，是我所見過的國內行業中唯一一塊過度設計了的模組，其他模組，大多都被視為對錶的增刪改查。從進入這個行業至今，大部分公司的系統許可權管理，都做到完全動態設定的，或者在力爭做到這一點。筆者本人也做過C/S下基於控制項的完全可配置的樹狀許可權控制系統。但所有這些產品都存在一個問題，許可權子系統被過度設計了。客戶所需要的，或者最終用到的，最多隻是十之二三。為何會出現這種情況呢，我想大多數公司或個人都想把許可權做成一個獨立的，強大的系統支撐模組，另外一點，國內客戶對許可權的要求非常簡單，出於以應

我們知道，一般的物件導向語言，都會有類，而類成員一般有三種存取權限：公開，保護，私人。有些人說，“保護”似乎沒有什麼價值，還建議不用。有些人卻認為，沒有“保護”，舉步維艱。我覺得，“保護”屬於類庫維護者，而“公開”屬於類庫使用者。只要我們明白這兩個身份的不同，就好理解該如何使用“保護”了。比如，你本身是類庫的設計者，或者是團隊設計者之一，那麼你也可能自己做自己的類庫維護者。但是類庫維護者並不好當。從介面的角度，“保護”成員對類庫維護者來說是屬於“介面”層級的，所謂介面，就要維持他的不變性。我們要

最近我在做一個WCF服務的開發，其安全要求是這樣的：server端使用wsHttpBinding綁定，SSL。基於AD做認證及授權。client端驗證資訊的方式採用UserName的方式，在服務端提供基於MembershipProvider或者UserNamePasswordValidator的定製驗證，採用windows內建的UseWindowsGroups方式，通過PrincipalPermissionAttribute來驗證。 之所以想採用這樣的驗證和授權組合，原因在於採用.net內建的M

Microsoft在.net 4.0中隊Workflow Foundation做了較大的調整，改變了自.net 3.0以來的工作流程思路，將WF提升為一種開發方式。尤其是和WCF做了無縫的整合，可以直接將一個工作流程暴露為WCF應用。在Windows Server AppFabric出來之後，我們可以可以在IIS中直接對WF WCF Application進行追蹤及持久化等諸多管理。其實在使用了WF以及WF WCF

對於web應用（包括web網站及web服務）的安全，我們首先想到的和見到的是，讓客戶提供憑據（最常見的是使用者名稱和密碼），然後服務端對客戶提供的憑據進行驗證，驗證通過後，在具體的方法調用或頁面請求時，根據驗證通過的客戶身份進行授權檢查，授權通過，則執行客戶的請求；反之則拒絕客戶的請求。這就是一般驗證及授權的思路。 如果這樣還不能安全要求，那隻好再啟用傳輸層加密，即SSL了。實際上在WCF中，驗證方式也被分為兩個層次：Transport和Message。在傳輸層加密資料，在訊息層提供憑據驗證及授

漢語編程，解決了13億中國人編程難的問題，我認為絕對夠格獲得諾貝爾獎！人們經常懷疑漢語編程的必要性和可行性，認為漢語編程是在扯淡。下面我就針對這些觀點來發表自己的看法。1.漢語不適合用來思考編程問題駁：自然語言中，漢語算是比較成功的。如果漢語不適合，英語等其他語種也會有同樣的問題。2.漢語不利於國際交流駁：交流是雙向的，不能老是我們中國人無條件的接受別人的標準，有時候也需要我們制定一些標準讓別人來履行。在國際上，英語確實是用得比較多，如果程式要多國協作開發，那麼漢語可能不是那麼合適。但這種程度的

360手機版安全衛士，在安裝成功後，預設開啟了“自動ip撥號”，而且預設ip號碼為17951。如果你用的是神州行暢聽卡（原神州行）的話，你在安裝360手機版安全衛士後一定要小心一點，進入“設定”仔細查看一下相關的設定。最好取消掉“自動ip撥號”，或者根據你的實際需要來設定。為什麼呢？因為如果你的卡是神州行暢聽卡的話，打長途號碼，前面加12593可以享受優惠（3毛9），如果加的是17951，那麼不但安裝4毛9收費，還要收取3毛的網路話費，也就是高達7毛9的話費。反過來，我不知道神州行福士卡前面加1

比如，重寫一個類TextBox的Control,那麼自然也希望它能夠像TextBox一樣，拖到表單上後，只可改變寬度，不可改變高度，除非修改了Font。對這個功能的實現，其實非常簡單，之所以貼出來，就算是方便大家吧。例碼：[Designer(typeof(XControlDesigner))]public class XControl:Control{    ...//具體實現}public class

部落格園的部落格開通了有3年多了，從最開始不敢寫，到後來不願寫，如今，回到這裡，開啟這一片久違的窗，一種重重的感覺縈繞在我心頭---我不能丟下它，任它荒蕪。說了一些不舍的話，歸根結蒂還是覺得自己沒有在部落格上找到感覺，或者技術的路一直過於粗糙而隨性，沒有精細的錘鍊過，或者留給自己的考慮時間也的確太少。最近換了個新的環境，Microsoft的技術為主打，幾乎Microsoft的技術都有所涉獵，想到部落格園也以Microsoft的技術傳播為主，所以這間舊居算是最適宜居住的了。希望我的這次決定能夠養成

最近在做自己的進銷存軟體，為了把TextBox改成與管家婆中的TextBox（一條底線）一樣，參考了CodeProject上的兩篇文章，做了一個UserControl，改UserControl具有如下功能： - 空間外觀切換:    ControlFormat:UnderLine,TextBox - 是否可以為空白:    Nullable - 可以控制字元長度/位元組長度:    LengthType:LetterLength,ByteLength    MaxLength -

<p$1$2$3$4$5$6> 物件導向有三個特性：封裝、繼承、多態。封裝是不容置疑的，就算不是物件導向，一樣有封裝的開發思想。多態，是能夠減少閱讀難度的方法，對合作開發有很大的協助。<p$1$2$3$4$5$6> 最讓人質疑，也是最有特色的是繼承。物件導向用很形象的思維，創造性的將現實世界的種類別關係納入開發指導中，但是正是這種類比，讓我產生了一種憂慮。是不是這個目標太過理想，反而讓人們忽視了其實質。肯定的，現實世界的種類別關係確實很普遍，我們完全有理由相信，編程使用類

WCF

最近在弄WCF Security(Authentication,Authorization)方面的解決方案，我想把各種驗證及授權的解決方案分別寫出來，一當做自己學習的總結，另外也與各位童鞋們探討、分享。今天先看看如何用RoleProvider來實現授權。RoleProvider，最初目的是用於滿足ASP.NET的授權要求，對於一般ASP.NET的應用，如果是Website，那麼這個用戶端認證資訊的類型(ClientCredentialType)是沒有（None）的。如果是Web

在使用PrincipalPermissionAttribute實現許可權控制的時候，關於PrincipalPermissionAttribute的用法，有幾點是需要注意的。1.PrincipalPermissionAttribute只能作用於類或其方法。PrincipalPermissionAttribute不能範圍介面及其介面方法。例如在定義WCF的服務契約時，不能將PrincipalPermissionAttribute放於服務介面或其方法之上。2.類層級的許可權控制優先於方法層級的許可權控

簡單工廠其實稱不上一個單獨的設計模式，因為它太簡單了，它是OO中最簡單的，也是最直接的，一個應用或初衷。什麼是工廠（Factory）？工廠（Factory）就是構造類的執行個體（Instance）的地方。為何要將類的執行個體的建立放到另外一個地方呢？Bus aBus = new Bus();這行代碼有什麼不妥嗎？是的，類的執行個體的建立和使用分開，才能夠使用到OO的好處，否則多態無法實現。如果說封裝定義了對象(object)的粒度，繼承保證了資料和行為的複用，那麼多態則在抽象的基礎上具有了應對各