其他

近期公司在做一個智能的點餐系統，是基於安卓系統開發的，簡而言之，就是用平板電腦點餐，雖然這個在國外已經流行了，但是在國內才剛剛起步。首先第一次我看到這個覺得很犀利，是的，以前沒用過，絕對會吸引很多的客人，而且很實用。 我嗎！總是喜歡異想天開，既然平板電腦點餐的是基於安卓系統，剛好My

  近期在公司的招聘中面試了一些候選人，但是結果都不理想。很多有5+年工作經驗的候選人，對於.net以及c#中的一些基礎知識都很難道出個所以然。  後來與團隊中的外方人員討論為什麼我們招不到合適的人？是不是我們面試的問題的問題太難了，太刁鑽了？  隨之分歧就來了，外方技術人員認為我們的問的問題很多都是答案都是是與否，考察的是知識點，但是很多候選人可能會因為各種各樣的原因，抑或緊張，抑或沒有考慮到，導致回答不了這些問題，所以不能因為這樣的問題去否決面試者。  

　　閑暇之餘準備開發一套電子商店的網站，要求能夠面對大資料量,高並發。我會將實現的全過程記錄下來，並通過部落格分享給大家，當然最後也會把這個電子商店網站免費開源，希望大家多多拍磚。我們的電子商店都準備實現哪些功能模組呢？商品管理商品類別管理打折管理評價管理訂單管理網站菜單管理首頁五圖連播管理內容管理許可權管理　　詳細描述，等我們下一個章節再說說道說道......

 　　ESB是企業服務匯流排（Enterprise Service Bus）的縮寫，是中介軟體技術與Web Service等技術結合的產物，也是SOA系統中的核心基礎設施。ESB就是一個服務的中介，形成服務使用者->ESB服務Proxy->服務提供者的生物鏈，中介的作用在不同應用中各有不同：解耦中介 ：客戶對實際服務提供者的身份、物理位置、傳輸協議和介面定義都是不知道也不關心的，互動整合代碼提取到了商務邏輯之外，由ESB平台進行中央的宣告式定義。ESB平台實現協議轉換

大家都比較喜歡使用三層架構，不過好多都是“貧血”的三層，並沒有發揮它的真正作用。今天項目中使用到了三層，發現一個結構圖畫的非常好就把它翻譯了下，重繪了一邊，並介紹下怎樣使用。相信大家對這個架構圖都比較熟悉。  使用方式：1、UI層展示和擷取資料，將資料通過Entity實體類傳遞到BL層。2、在BL層，將業務處理單元寫成函數，並將其封裝在BusinessFunction中，然後被BusinessFlow調用進行業務處理。當然“BusinessFunction”和“BusinessFlow”可以合起

一、詭異現象1、 在對一個項目的現場實施調試中，應用軟體系統在擷取服務端資料時報“操作失敗”，經日誌反饋為：WCF通訊逾時！2、 經過反覆測試發現：並不是所有操作都會失敗，像登入、增、刪、改、查等簡單操作能正常運行，只是在擷取某種資料量比較大的資料時會出現操作失敗的情況。3、現場環境為：Dell R710（伺服器）+Dell商用機（用戶端）+光纖網.4、我們的系統是C/S和B/S統一的行業應用軟體，採用WCF進行分布式通訊，並提供統一的應用服務。 二、問題分析1、 

  今天好不容易把sslic2.0調試好。Hello world！！也終於面試。激動之餘，開始了我的sscli之旅。由於調試sscli的那幾天，我沒有停歇，直接看sscli2.0的書籍，都是英文版的。煩啊。所以就直接開始了第一個程式echo.cs。看過《Shared Source CLI 2.0 Internals》的朋友都應該知道這個程式吧，是第一個教學程式。Ctrl+c、ctrl+v。進行調試，運行csc /target:library /debug

　　我不是一個架構師，寫下這些內容也僅作為個人的一點總結，以作拋磚引玉之用。 　　平常在談論系統架構時，我們常常會聽到類似“三層架構”、“多層架構”的說活，但是在嚴格的UML設計卻並沒有直接的對於“層”的形象描述;在典型的基於“4+1視圖”的架構設計文檔中也同樣沒有明確要求對“層”的形象分析。　　［注意：喜歡“層”的朋友，在4+1視圖時可在邏輯視圖中單獨添加對“層”的詳細說明］　　在基於UML設計時，我們往往會把“分層”的理念分解成“組件”和“包”的形式來展現，但作為一名.net開發人員來說，對

在看雪學院看到一篇好文章，發上來大家共用共用。http://bbs.pediy.com/showthread.php?threadid=31799這裡的原始碼自然不是指.net Framework的源碼，不過微軟公開了一個代號為rotor的open source cli的源碼，你可以把它看為輕量級的.net framework。最關鍵的是，它倆的運行機理大致相同。今天，我們就從rotor的源碼中看看做為程式調試最基本的exe檔案的動態載入。同樣，先給出參考文獻，免得有人說我抄襲。《inside 

    在我們建立一個簡單的工作流程樣本之前，讓我們開啟VS2010，通過“檔案.建立.項目”後進行1-1所示，並選中“Workflow”節點，這裡我們會發現其中有4個模板。    同時在“名稱”欄中輸入：Chapter01，並選擇“工作流程控制台應用程式”模板後，點確定。 （圖1-1） WF之“Hello World!”    這時模板將自動產生一個具有簡單工作流程功能的架構，通過VS2010 IDE我們可以看到如所示。 （圖1-2）  

    在WF4.0中提供了一系列如“If”、“Whiel”、“Assign”和“Sequence”等程式要素，（註：這些要素與我們在C#語言中的關鍵字is, while,=,List類似），為了說明這些要素是如何工作的，我們會設計一個“祝福”程式，類似老式的“座鐘”報時一樣，發出“鐺”的聲響。    首先，讓我們的解決方案中開啟“Workflow1.asmx”檔案。 使用變數   

不是說Rotor是公開的源碼嗎？怎麼找不到RumtimeType這個源檔案啊。最近在研究它的reflection機制。在一句代碼 Type t = cust.GetType();//cust是一個對象MethodInfo method =

前些天，看了一篇博友的文章，說自己要嘗試寫寫博文，其實我也有此想法久矣，但總是推脫說忙，其實是忙於遊戲。我來部落格園很久了，就像一個小偷，總是在竊取別人的心得、經驗和成果，以為己用。而自己卻沒有半點鐘分享與貢獻，有時也會覺得慚愧和自私。以前總覺得自己才疏學淺，難登大雅之堂，以至每每想試而又退縮；今天想想“文學切磋是不分輩分的”也就釋然。再者，就算自己所寫的所說的一文不值也可作“引玉之拋磚”或是“反面教材”，對自己可謂是進步，於他人也可作為借鑒。萬事開頭難，立帖紀之。

通過《Beginning WF4讀書筆計 － 第一章 01建立一個簡單的工作流程》和《Beginning WF4讀書筆計 － 第一章 02添加程式元素》的介紹後，本樣本基本完成。我們可以看到其總體設計示圖如下 (圖1-20) 同時，我們也可以通過選中“Workflow1.xaml”右鍵，“查看源碼”來查看這些工作流程所對應的XAML代碼。 (圖1-21) 此時，哪果設計器處在開啟狀態時，會提示一個警告： (圖1-22) 點擊“是（Y）”，便可查看源碼，以下示圖為部分截取。 (圖1-23) （註：

    UML,整合模組化語言，在軟體系統分析和設計中被廣泛應用。作為一個初學者，我們總會感覺UML很複雜，有時候會感覺不知從何下手，有時會候也會困惑不同的UML圖應該用在什麼場合才較為合適。    

    在上一章中，我們通過工作流程引擎設計器成功的實現了一個簡單的工作流程樣本。接下來我們將採用後台代碼的方式來實現同樣的一個流程。 控制台程式    首先建立一個控制台程式     添加對“Systm.Activties”的引用（註：這個庫在進行工作流程開發時必須引用的）    同時更改Program.cs中的命名空間如下：using System;using System.Activities;using System.Activities.Statements;using System.

    每一個產品的需求是對現實世界特定問題的一種描述，而有些問題描述可能是非常的錯綜複雜，以至在我們對其進行分析時，會覺得無從下手甚至不知所措。    需求分析是系統設計和開發的基礎，需求分析的好壞會直接影響後繼設計和開發的品質，嚴重時會影響到系統的成敗。UML中的使用案例圖就是為了方便我們分析與交流產品需求而生，同時也為我們把產品需求轉化為系統需求提供方便。        

    在本章中，我們將建立基於“Flowchart”活動的工作流程。其實通過名稱我們可以猜到“Flowchart”活動與我們平常所說的流程圖類似；這些活動都是通過判斷條件來相互串連的。    使用“Sequence”活動時，所有的子活動都是由上到下順序執行的，但是基於“Flowchart”的活動，其子活動則可以按其分支條件進行的，可以任意順序執行。 建立“Flowchart”工作流程    建立一個控制台的工作流程解決方案，如下：  設計“Flowchart”   

     在上一篇《UML系統分析與設計02－使用案例圖和活動圖表（上）》中，我們主要講解了在需求分析中的用例分析和繪製的方法和技巧，但是使用案例圖只告訴我們系統要“做什麼”，至於“怎麼做”卻並沒有很直觀的描述。為了更形象的說明我們的系統是如何一一滿足使用者需求的，並向使用者提供“怎麼做”的細節描述，我們將使用“活動圖表”來對用例進行補充性說明。    [ 注意：UML中並沒有說“活動圖表”是用於對“使用案例圖”補充說明，但就我個人而言我更喜歡這樣來定義它，並在實踐中進行應用。]   

 FlowSwitch    其實“FlowSwitch”活動與“FlowDecision”活動類似，只不過“FlowSwitch”可以有不受限制的分支個數，而“FlowDecision”只有“True/False”兩個分支。功能與C#中的“switch”關鍵字有類似的功能。    在設計器中“FlowSwitch”活動形狀如下：  添加“FlowSwitch”活動