其他

    啥也不說，：     這是最基本的增刪改查代碼！     符合X系列組件的一貫作風，不求萬能，只求簡單實用！     不支援多表查詢，所以不是萬能的，僅僅支援單表，所以是簡單的，增刪改查都得到了直接支援，完全能解決80%以上的情境，所以是實用的。    

當我在設計一個Composition SDK的時候，我遇到了一個由單重繼承引起的問題。請先看一下類圖。 介面組合思路與微軟的CAB類似。遇到的問題就是：1 在圖中存在繼承了類B的類A需要繼承類C的功能，但是單重繼承又不能使A繼承C，如何解決呢？ 2

    這裡以日誌組件XLog作為開頭，不再以專門的概要或者目錄說明開始，體現新生命Team Dev組件體系的基本思想——追求實用，一切從簡！     我寫文檔資料向來行文自如，沒有統一的格式。基本上標題是粗體二號置中，本文是小四，段落首行縮排2字元，行間距1.5倍。我比較喜歡上彩色的代碼，因為那樣閱讀起來非常舒服，有時候乾脆直接用代碼替代。       就讓我們從日誌組件XLog開始吧！    

在最開始做可視化應用的時候，從來沒有考慮過如何組織代碼結構。後來開始接觸了3層甚至N層，接觸了UI映射、ORM映射，借鑒這些我自己也設計了O-O映射和控制項關係映射。後來我接觸了UI Composite Application Block（CAB）和SCSF，覺得其組合設計思想非常的不錯，還花了2個月時間把OB和UI App

文章目錄 1、為什麼要向資料庫隨機插入資料2.功能要求3.開發過程4.改進 -上一篇介紹了Xcode的資料庫反向工程的相關知識後，今天正好使用Xcode向資料庫插入隨機資料，特地記下，方便後來學習的人。有關Xcode的基礎使用知識，還請大家自行到開源的網站和論壇去，也可以在論壇提問。下面進入正題:1、為什麼要向資料庫隨機插入資料     

文章目錄 1.為什麼要進行資料庫遷移2.功能要求3. 開發過程   先說明一下，本文使用的Xcode不是Mac的Xcode，而且Newlife團隊開發的一個.NET開發組件。其曆史也有將近10年，因此大家不要誤會。新生命Team Dev的相關資訊：QQ群：1600800部落格：http://nnhy.cnblogs.com論壇：http://www.53wb.com開源地址：http://xcode.codeplex.com/    

在.NET發展史中，2.0是具有裡程碑意義的一個版本。從這個版本，.NET青出於藍(Java)，而勝於藍。在.NET 2.0帶來的諸多新特性中，我認為泛型是最重要，沒有之一。雖然泛型出現已有多年，連Java都早已借鑒引入了泛型（雖然是文法糖），可是用泛型的編程思維方式並沒有得到相應的普及。一方面是由於過去大量的Framework仍然是在非泛型時代寫成的，另一方面泛型的設計模式沒有得到發展，改變的時候該到了。來舉一個例子說明這兩點。我們如果寫過網路資料抓取的代碼，應該熟悉這樣的代碼：var

Facebook、Google這樣的巨頭IT公司都具備完善的程式碼程式庫管理、代碼審計（Code

上一篇擁有自己的代碼產生器—NewLife.XCode代碼產生器分析簡單的分析了Xcoder的原理，並通過快速調用模板引擎產生了代碼，對調用引擎前後的注意事項也說了一下，本篇主要來介紹模板的編寫及規則。上一篇已經貼出了 產生的程式碼，當然這個代碼也是你編寫模板之前需要考慮的，的確是要產生這個樣子，然後才能去編寫對應的模板。關於模板引擎的說明，Newlife團隊的大石頭有一篇部落格很經典，大家可以去參考一下，  模版引擎XTemplate與代碼產生器XCoder（源碼）

我曾經聽過一個老師對一個做的不錯的程式員的一句評論：“某某某做程式確實很快，但就是都不能用”。事實上，直到今日，我們中很多人仍然在寫這樣的程式。不能用的程式一般都有幾個特徵，比如當程式出現問題時，總是不知道該怎麼處理，甚至是在正常情況下都會出現問題，但歸根結底就是壓根就沒有認真從使用者的角度來考慮使用者到底怎麼來使用。如果使用者輸入了程式接受的輸入，那麼必然該給出正確的結果，可悲劇的是，就是有那麼多的意外，因為客戶行為總是在很多程式員意料之外，因此，當使用者執行了某個程式員認為是非常規的操作的話

4 基於RoundTrip（往返）的通訊協議設計通訊伺服器外掛程式的核心為3部分：（1）與通訊方式、商務邏輯無關的通訊協議實現；（2）和通訊方式、商務邏輯有關的通訊商務邏輯的實現；（3）遠程通訊訊息佇列。在這裡我將重點描述通訊協議的實現。這個通訊協議的實現比較靈巧。4.1

健壯的程式並不是沒有異常，而是能夠處理異常和定位異常！ 去年給客戶諮詢的時候，客戶提出一個非常有趣的問題：他們做的一個應用系統經常動不動就掛掉，而且最主要的是，掛掉後無法找出問題的原因。後面查看代碼時，發現使用者在編寫代碼中，出現了類似以下的代碼。1 IPageFlowService pageFlowService = 2     bundleRuntime.GetFirstOrDefaultService<IPageFlowService>();3 // Redirect to f

1.前言最近一個人狂看X組件的源碼，從CommonEntity到XCode，然後XCoder到XCode。感覺自己有很大的進步，視野更加開放，也能夠更加順手的做很多事情。大石頭在5月份左右的時候，錄製了幾期視頻教程，其中有一期“使用對象容器來解耦業務模組與管理平台”，對理解X組件很有好處，這期視頻我前後已經聽了4遍，當然每聽一遍都有一些新的發現與體會。今天要總結也是對象容器的一點理解以及為瞭解決問題，在XCoder源碼中發現的一些東西：介面操作。 2.XCode對象容器介紹 XCode對象容器的

在很多情況下，我們都非常期待使用自動升級來幫我們發布和部署應用程式更新。對於一個上規模的產品，自動化部署、升級的實現，對於軟體測試和最終部署都可以避免手工升級的麻煩，減少瑣碎的工作，節省資源。在部署過程，或者開發/QA人員協作過程中，這種重複性的勞作非常厭煩且容易出錯。此外，當一個產品最終發布後，自動升級對於很多產品來講是無可或缺的。現在讓我來分享一下我們的自動化升級方案，這個方案通用於.NET平台的任何應用，WinForm、WebForm、MVC等所有應用，都可以實現自動化部署和升級。1

在這個文章裡，我將分享一下在iOpenWorks.com這個網站試運行中碰到的若干問題和解決方案，這些問題包含了：（1）如何通過ASP.NET MVC先行編譯提高效能；（2）如何知道網站在運行中，使用者響應速度、網站異常資訊、使用者操作習慣；（3）解決與DiscuzToolkit整合的線程同步問題。 1 ASP.NET MVC 3先行編譯支援提高網站效能，除了我們常見的壓縮、CDN、緩衝之外，還有一個就是使用先行編譯。不管是ASP.NET WebForm，或者是ASP.NET

這個通用介面架構是基於OSGi.NET外掛程式架構來做的，先看一下運行效果。換個皮膚試試看！這個介面架構是OSGi.NET面向服務外掛程式平台的一個通用的介面外掛程式，OSGi.NET面向服務外掛程式架構是一個支援WinForm、Web、WPF、Silverlight，甚至是行動裝置

由於Newlife.XCode組件中大量的地方使用了泛型基類，以前也是很迷糊，似懂非懂。所有春節前整理了一份文檔，把泛型基類的知識總結了一下，特意分享出來。本文大部分內容摘自XCode的相關介紹說明以及如下2篇文章，只是整理了一下：http://www.cnblogs.com/XmNotes/archive/2012/04/23/2466938.htmlhttp://www.cnblogs.com/zgynhqf/archive/2010/09/28/1837567.html在.NET發展史中，

上篇文章《發布一個免費漂亮的仿Outlook風格、支援換膚的通用介面架構》提供了一個漂亮的Outlook風格、支援換膚的通用介面架構。現在，我們先來通過源碼學習如何開發一個簡單的介面架構，後面我們再發布源碼介紹如何開發Outlook風格、支援換膚的介面架構。點擊以下連結下載該樣本架構 簡單介面架構源碼下載。1 簡單介面架構概述1.1

在這裡，我將分享一個Outlook風格介面架構的原始碼，並詳細介紹如何介紹一個漂亮、通用、可擴充、可換膚的介面架構。首先，我們來看一下這個架構的運行效果。你可以從以下地址下載該架構的可執行程式：Outlook風格介面架構。下面我們來介紹一下如何構建這樣的介面架構。1

1 遠程分布式監控與控制系統設計概述1.1 概述該系統由通訊伺服器、Web管理平台、訊息佇列伺服器和資料庫伺服器構成。這裡，我將在本文要描述的內容摘要如下。（1） 基於OSGi.NET的動態部署（自動升級）、模組化開發方法：整個系統由Web管理平台（這個文章不詳細描述）和通訊伺服器組成，由5個軟體開發人員協作開發（硬體開發工程師若干），目前有多個地區的部署。（2）