C#

[ASP.NETMVC 小牛之路]09 - Controller 和 Action (1)我們知道，在 MVC 中每個請求都會提交到 Controller 進行處理。Controller 是和請求密切相關的，它包含了對請求的邏輯處理，能對 Model 進行操作並選擇 View 呈現給使用者，對於業務和資料的邏輯代碼以及介面和輔助類庫等一般都不放到 Controller 中。Controller 和 Action 的內容較多，我把它分成了兩篇，也可能會分成三篇。本篇介紹 Controller

[ASP.NETMVC 小牛之路]08 - Area 使用ASP.NET MVC允許使用 Area（地區）來組織Web應用程式，每個Area代表應用程式的不同功能模組。這對於大的工程非常有用，Area 使每個功能模組都有各自的檔案夾，檔案夾中有自己的Controller、View和Model，但對於管理也增加了一定的難度。本文目錄建立Area右鍵工程選擇 添加->地區，彈出如下填寫Area的對話方塊：點擊添加後，工程目錄結構如下：和建立一個空MVC工程結構類似，Admin Area

[ASP.NETMVC 小牛之路]06 - 使用 Entity Framework在家閑著也是閑著，繼續寫我的[ASP.NET MVC 小牛之路]系列吧。在該系列的上一篇博文中，在顯示書本資訊列表的時候，我們是在程式碼中手工造的資料。本文將示範如何在ASP.NET MVC中使用EntityFramework從資料庫中擷取資料。雖然本文題目聽上去比較簡單，但如果你認真閱讀，相信你一定會有所收穫。本文目錄：ORM 和

[ASP.NETMVC 小牛之路]05 - 使用 Ninject在[ASP.NET MVC 小牛之路]系列上一篇文章（依賴注入(DI)和Ninject）的末尾提到了在ASP.NETMVC中使用Ninject要做的兩件事情，續這篇文章之後，本文將用一個實際的樣本來示範Ninject在ASP.NET

[ASP.NETMVC 小牛之路]04 - 依賴注入(DI)和Ninject本文目錄：為什麼需要依賴注入在[ASP.NET MVC 小牛之路]系列的理解MVC模式文章中，我們提到MVC的一個重要特徵是關注點分離(separation of

[ASP.NETMVC 小牛之路]03 - Razor文法Razor是MVC3中才有的新的視圖引擎。我們知道，在ASP.NET中，ASPX的視圖引擎依靠<%和%>來調用C#指令。而MVC3以後有了一套新的使用@標記的Razor文法，使用起來更靈活更簡潔。下面通過一些簡單樣本讓大家快速撐握Razor文法的使用。本文目錄準備工作在示範Razor文法的使用之前，我們需要做一些準備工作。1.開啟VS建立一個ASP.NET

[ASP.NETMVC 小牛之路]02 - C#知識點提要本篇博文主要對asp.net mvc開發需要撐握的C#語言知識點進行簡單回顧，尤其是C# 3.0才有的一些C#語言特性。對於正在學asp.net

ASP.NETMVC 小牛之路]01 -

protected void Button1_Click(object sender, EventArgs e) { string filename = this.DropDownList1.SelectedValue;//最終命名 if (this.FileUpload1.PostedFile != null) { string baseFilename = this.FileUpload1.PostedFile.FileName;//擷取上傳檔案檔案名稱 int i =

最近涉及到用asp.net做上傳功能的一個問題，因為asp.net有fileupload的上傳控制項，但是這個控制項上傳的檔案大小有限，所以根本滿足不了需求百度了下，很多人遇到asp.net上傳超大檔案的困惑，偶爾搜尋發現csdn有個哥們提到這個超大檔案如何?，RadUpload.Net2.dll並且提供了這個動態庫進行處理超大檔案的上傳處理過程。於是就下載下來看了看，果然效果不錯，不但支援吵過700M的檔案上傳快速，更重要的是支援多線程的上傳檔案。查看原始碼發現利用的控制項也是fileuplo

前些天一位朋友要我幫忙做一單點登入，其實這個概念早已耳熟能詳，但實際應用很少，難得最近輕閑，於是決定通過本文來詳細描述一個SSO解決方案，希望對大家有所協助。SSO的解決方案很多，但搜尋結果令人大失所望，大部分是相互轉載，並且描述的也是走馬觀花。 閑話少敘，進入正題，我的想法是使用集中驗證方式，多個網站集中Passport驗證。 如所示： 為方便清晰描述，先定義幾個名詞，本文中出現之處均為如下含義。 主站：Passport集中驗證伺服器 http://www.passport.com/ 。

在之前的部落格中已經非常詳細的介紹了Redis的各種操作命令、運行機制和伺服器初始化參數配置。本篇部落格是該系列部落格中的最後一篇，在這裡將給出基於Redis用戶端組件訪問並操作Redis伺服器的程式碼範例。然而需要說明的是，由於Redis官方並未提供基於C介面的Windows平台用戶端，因此下面的樣本僅可運行於Linux/Unix平台。但是對於使用其它程式設計語言的開發人員而言，如C#和Java，Redis則提供了針對這些語言的用戶端組件，通過該方式，同樣可以達到基於Windows平台與Red

一、特殊編碼： 自從Redis 2.2之後，很多資料類型都可以通過特殊編碼的方式來進行儲存空間的最佳化。其中，Hash、List和由Integer組成的Sets都可以通過該方式來最佳化儲存結構，以便佔用更少的空間，在有些情況下，可以省去9/10的空間。

一、請求應答協議和RTT： Redis是一種典型的基於C/S模型的TCP伺服器。在用戶端與伺服器的通訊過程中，通常都是用戶端率先發起請求，伺服器在接收到請求後執行相應的任務，最後再將擷取的資料或處理結果以應答的方式發送給用戶端。在此過程中，用戶端都會以阻塞的方式等待伺服器返回的結果。見如下命令序列： Client: INCR X Server: 1 Client: INCR X Server: 2 Client: INCR X Server: 3

一、概述： Redis在設計之初就被定義為長時間不間斷啟動並執行服務進程，因此大多數系統配置參數都可以在不重新啟動進程的情況下立即生效。即便是將當前的持久化模式從AOF切換到RDB也無需重啟。 在Redis中，提供了一組和伺服器管理相關的命令，其中就包含和參數設定有關的CONFIG SET/GET command。二、相關命令列表：命令原型時間複雜度命令描述傳回值CONFIGGETparameter

一、簡介： 和大多NoSQL資料庫一樣，Redis同樣遵循了Key/Value資料存放區模型。在有些情況下，Redis會將Keys/Values儲存在記憶體中以提高資料查詢和資料修改的效率，然而這樣的做法並非總是很好的選擇。鑒於此，我們可以將之進一步最佳化，即盡量在記憶體中只保留Keys的資料，這樣可以保證資料檢索的效率，而Values資料在很少使用的時候則可以被換出到磁碟。

一、Redis提供了哪些持久化機制： 1). RDB持久化： 該機制是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟。 2). AOF持久化: 該機制將以日誌的形式記錄伺服器所處理的每一個寫操作，在Redis伺服器啟動之初會讀取該檔案來重新構建資料庫，以保證啟動後資料庫中的資料是完整的。 3). 無持久化： 我們可以通過配置的方式禁用Redis伺服器的持久化功能，這樣我們就可以將Redis視為一個功能加強版的memcached了。 4).

一、Redis的Replication： 這裡首先需要說明的是，在Redis中配置Master-Slave模式真是太簡單了。相信在閱讀完這篇Blog之後你也可以輕鬆做到。這裡我們還是先列出一些理論性的知識，後面給出實際操作的案例。 下面的列表清楚的解釋了Redis Replication的特點和優勢。 1). 同一個Master可以同步多個Slaves。 2).

一、概述： 和眾多其它資料庫一樣，Redis作為NoSQL資料庫也同樣提供了事務機制。在Redis中，MULTI/EXEC/DISCARD/WATCH這四個命令是我們實現事務的基石。相信對有關係型資料庫開發經驗的開發人員而言這一概念並不陌生，即便如此，我們還是會簡要的列出Redis中事務的實現特徵： 1). 在事務中的所有命令都將會被序列化的順序執行，事務執行期間，Redis不會再為其它用戶端的請求提供任何服務，從而保證了事物中的所有命令被原子的執行。 2).

一、概述： 在該系列的前幾篇部落格中，主要講述的是與Redis資料類型相關的命令，如String、List、Set、Hashes和Sorted-Set。這些命令都具有一個共同點，即所有的操作都是針對與Key關聯的Value的。而該篇部落格將主要講述與Key相關的Redis命令。學習這些命令對於學習Redis是非常重要的基礎，也是能夠充分挖掘Redis潛力的利器。