開發 ASP.NET vNext 續篇：雲優化的概念、Entity Framework 7.0、簡單吞吐量壓力測

小分享：我有幾張阿裡雲優惠券，用券購買或者升級阿裡雲相應產品最多可以優惠五折！領券地址：https://promotion.aliyun.com/ntms/act/ambassador/sharetouser.html?userCode=ohmepe03 繼續上一篇《開發 ASP.NET vNext ...

小分享：我有幾張阿裡雲優惠券，用券購買或者升級阿裡雲相應產品最多可以優惠五折！領券地址：https://promotion.aliyun.com/ntms/act/ambassador/sharetouser.html?userCode=ohmepe03

繼續上一篇《開發 ASP.NET vNext 初步總結（使用Visual Studio 2014 CTP1）》之後，

關於雲優化和版本控制：

我本想做一下MAC和LINUX的self-host測試，但是官方說運行環境的MONO版本至少需要3.4.1，我去年買了個表，至本文發佈為止，你讓我下地獄去找3.4.1嗎，硬著頭皮用3.4.0搞了一晚上，MAC一直停留在 httpapi.dll出錯，Ubuntu Server 12.0.4 是不認其中的幾個DLL包，具體哪幾個也忘了，過段時間有了穩定版本再弄吧。

但是，我因此卻大概瞭解了它所謂的“雲優化“是什麼概念，先來看看如何在非windows環境運行一個項目的完整步驟：

把生產環境代碼部署到某個全新的平臺上（*nix與MAC）之後，進入當前代碼目錄下
運行sudo kpm restore 命令
k運行時環境會根據project.json中記錄的各個命名空間，自動聯網恢復當前整個項目所需的包
包保存到本地
運行 k web ，啟動self-host模式，或者 k run ，啟動nginx等第三方宿主模式。"web"和"run"參數對應project.json中的相應節點配置。

在步驟3，不同的系統會得到不同的包，這就是所謂的雲優化。

如果以後需要更新包的版本，使用 kpm upgrade 來更新，依舊是手動，除了”.net 4.5 core“這個最核心的命名空間是從系統載入之外，其它的整個運行環境所需的全部包，都保存在你自己當前的目錄下，從你自己的目錄裡面載入運行，相當於”綠色版“ASP.NET，舉例來說，從前總有些功能是即使你把dll放到bin也沒用的，必須是通過系統安裝才可以使用，而現在，它可以100%的保證你所需的全部功能都可以通過把dll部署到bin目錄來解決，這樣做的實際意義是：aws和azure的linux主機不允許我們運行root用戶，總有些東西是我們哪怕sudo也沒法安裝的，這隻是其中一例，至此明白我的意思就好，進而的，我們可以把同一個應用程式的不同版本部署到不同的目錄，綁定不同的功能變數名稱，完全隔離它們的運行期上下文，這就是所謂的每個應用程式可以運行於不同的版本。

關於從nuget載入包的擔心：

初次啟動它不會自動去nuget載入，下次再怎麼重啟也更不會去nuget自動載入，一切涉及到nuget的行為都需要你自己手動控制，restore時只有100%成功載入後，你的應用程式才能夠運行，否則回滾，upgrade也一樣必須是100%成功，否則回滾，你把它想象成一個“事務”來理解就可以了，不會在“載入”這件事上對你的應用程式造成影響。

此nuget也非彼nuget，預設情況下它會到nuget官方伺服器載入包，但是kpm restore 和 upgrade 可以指定不同的源地址，如果你願意，你可以指定到127.0.0.1。所以到此為止，不需要在部署上有什麼擔心了。

關於VS2014:

根據微軟向來的潛規則，某個組件還在測試版本階段的時候，它的命名空間是：Microsoft.XXX.XXX，待到正式版本發佈後，會變成System.XXX.XXX。目前很多包都是Microsoft名下。

我目前的VS2014 CTP1是在卸載掉本機的2013、2012、2010之後才順利安裝上的，但是也不知道是我卸載過程中卸錯了東西還是VS2014 CTP1本身作怪，我系統上的SQLServer光榮犧牲掉了，重新安裝一遍SQLServer就好（修複安裝），雖然它說了不能與舊版本的VS共存於同一臺機器，但是我後來再次安裝上了VS2013.2，一切工作正常。（有風險，請勿仿效，本人不負責一切後果）

有時候你編輯著一個項目，一切風平浪靜，但是當你保存，關閉vs2014，再次打開vs2014開啟項目後，項目中的“引用列表”會一直停留在loading狀態，重啟幾次後才好，鬼才知道是為什麼。

凡事講究門當戶對，既然時代已經進入vNext，不用EF 7.0怎麼對得起D和人民：

Entity Framework 7.0 ：更加簡潔，可惡的Migration終於離去

（Entity Framework 7.0可以獨立於vNext，運行於MVC1~5.x）

創建好一個示範用的資料庫之後，看看：

在過去，使用Migration的時候遇到的最大問題，不是Migration步驟本身，而是時不時出現：“已經存在相同的表或對象”，各種解法稀奇古怪，甚至需要去修改Migration自動生成的文件，自己玩玩的項目就算了，真正大規模實時生產環境裡面你敢這麼做?

在過去，Migration表中記錄了每個數據表的結構Hash值，如果你手動修改了表結構，哪怕是實際已經保持了結構的一致性，但是Entity Framework依然會報錯，因為Hash值不對，它只相信它自己的Migration，雖然可以通過應用程式初始化期間關閉數據結構檢查來越過Migration步驟，但是依舊心慌慌的，出門和人吹牛也怕被因此抓到把柄。現在，Migration終於消失了，意味著你可以自己去手動修改表結構與Code First結構同步，它再也不會自作聰明來為難你了。

由此帶來的另一個好處：省掉該功能後，同時也意味著省去很多開發與測試步驟，EF團隊能夠更專註於EF本身的核心功能，更快速更新/修複版本，第三方資料庫開發商可以更快速地發行/更新與自己的資料庫對應的Entity Framework框架。

你依然可以使用Migration，系統把這個功能分離出來放置在Microsoft.Data.Entity.Migration空間下，至於怎麼去使用，我就沒去研究了。

過去，在運行時，Entity Framework 會自動檢查資料庫是否存在，如果不存在，就自動創建一個資料庫，並且創建對應的表等所有對應結構。現在這個功能需要我們手動去開啟，並且“創建資料庫”與“創建表”還是兩碼事，就像這樣：

    /// <summary>
    /// 資料庫操作類
    /// </summary>
    public class DBOperator : DbContext
    {
        public DBOperator() 
        {
            if (!Database.Exists())
            {
                Database.Create(); //創建資料庫
                Database.CreateTables(); //創建表
            }
        }

        public DbSet<Customers> Customers { get; set; }

        protected override void OnConfiguring(DbContextOptions builder)
        {
            builder.UseSqlServer(@"Server=HP\SQLSERVER;Database=vNextTest;Trusted_Connection=True;MultipleActiveResultSets=true");
        }
    }

在1~6.x版本中，你可以把構造函數去掉，沒問題，系統會自動創建資料庫和表，但是現在不行了，如果你刪掉上面代碼例子中的構造函數，資料庫不會在一開始得到創建，由此引發了這麼一種思考: 在實際運行過程中，99.9999999999%的情況里是不需要去if (!Database.Exists())的，我們就可以通過構建一個多態結構來這麼做，確保性能的最大化：

    public abstract class DBO : DbContext
    {
        public DbSet<Customers> Customers { get; set; }

        protected override void OnConfiguring(DbContextOptions builder)
        {
            builder.UseSqlServer(@"Server=HP\SQLSERVER;Database=vNextTest;Trusted_Connection=True;MultipleActiveResultSets=true");
        }
    }

    public sealed class DBOperator : DBO
    {
        //實際運行時使用這個類
        //省去不需要的判斷
    }

    public sealed class FirstTime : DBO
    {
        public FirstTime() 
        {
            //系統第一次運行時使用這個類，把它放在Started.cs中執行一次就好了
            if (!Database.Exists())
            {
                Database.Create(); //創建資料庫
                Database.CreateTables(); //創建表
            }
        }
    }

設置project.json，啟用Entity：

{
    "dependencies": {
        "Helios" : "0.1-alpha-build-0585",
        "Microsoft.AspNet.StaticFiles": "0.1-alpha-build-0443",
        "Microsoft.AspNet.Mvc": "0.1-alpha-build-1268",
        "Microsoft.AspNet.Server.WebListener": "0.1-alpha-build-0520",
        "Microsoft.Data.Entity": "0.1-alpha-build-*", //啟用Entity
        "Microsoft.Data.Entity.SqlServer": "0.1-alpha-build-0863", //啟用SQL Server
        "Microsoft.DataAnnotations": "0.1-alpha-build-0100", //啟用DataAnnotations
        "Microsoft.Framework.ConfigurationModel": "0.1-alpha-build-0233" //啟用配置文件操作
    },
    "configurations" : {
        "net45" : { },
        "k10" : { }
    }
}

其它的SaveChange、Add等操作和從前一樣，就不說了。

同道中人們，從現在開始，請扔掉Migration。

vNext運行於self-host模式和IIS模式，對比傳統MVC 5.x

下麵是使用AB對vNext做一個簡單壓力測試，主要是對吞吐量有個心理概念，controller中進行斐波那契序列30次迭代運算，View是空的，只輸出簡單HTML，客戶端模擬1000個用戶總共進行10000次訪問。每次測試前，都額外通過IE訪問一次（消除初次啟動）。

        public IActionResult Index()
        {
            var x = new int[30];
            var length = x.Length;

            for (int n = 0; n < 30; n++)
            {
                switch (n)
                {
                    case 0:
                        x[n] = 1;
                        break;
                    case 1:
                        x[n] = 1;
                        break;
                    default:
                        x[n] = x[n - 1] + x[n - 2];
                        break;
                }
                this.Context.Response.WriteAsync((x[n]).ToString() + "<br />");
            }

            return View();
        }