EF7 的糾纏
ASP.NET 5 的無助
忘不了你的好
對 ASP.NET 5 和 EF7 的感情，從她倆一出生，我就不可自拔的愛上她們了，不要嫌哥多情，有“情”，就是任性。
從一開始的一見鐘情，到慢慢的深入了解，再到最後的抉擇與無奈，不管結局如何如何，其實這個過程，已經讓我們彼此學到了很多，也成長了很多。
對于 EF7 的項目應用，我自己是充滿信心的，不管遇到什麼問題，我也都想盡辦法去解決，無奈的是網上資料太少，谷歌搜尋一些 EF7 問題關鍵詞，基本上找不到對應的解決方案，是以有些東西隻能自己去摸索，去實踐，但這樣也會造成，往往一個很簡單的問題，自己卻想的很複雜，最後就不知不覺的陷在裡面，而且越是解決不了，自己就越想解決，然後就陷入一個惡性循環，最後呢？這個問題還是沒有解決，這樣所造成的結果是什麼呢？很簡單，寶貴的時間被浪費了，沒辦法，這也是新技術所應用的成本。
我記得有一個 EF7 Migration 的問題，這個問題大概花了我兩三天的時間，是的，兩三天的時間啊，一直在解決這個問題，最後呢？很顯然，沒有解決，而且之後的幾天一直在郁悶，壓抑的感覺越來越強烈，當一個問題存在你心中很久很久，你就越想解決它，這個想法也就會變的越來越強烈，是以你需要你個發洩點，什麼呢？就是寫博文。轉移注意力，也算是一種吐槽，就紀錄了一篇博文：
<a href="http://www.cnblogs.com/xishuai/p/ef7-develop-note.html">EntityFramework 7 開發紀錄</a>
其實你發現，EF7 Migration 的問題解決很簡單，就是換一種方法：使用 KVM 進行指令操作，而我那幾天時間卻一直撲在：怎麼使用 Package Manager Console 進行 EF7 Migration 操作？而且一直陷在裡面，最後卻解決不了。是以通過這件事，我自己也收獲了一點，那就是如何解決問題？如果一個問題在一個場景中自己始終解決不了，不妨跳出這個場景，換一種思路去解決，不經意的一瞬間，也許這個問題就可以解決了。當然收獲的最重要一點是：有問題，寫博文，抛出問題，之後零零散散紀錄了一些：
<a href="http://www.cnblogs.com/xishuai/p/ef7-smallint-short-where.html">EntityFramework 7 smallint short 奇怪問題（已解決）</a>
<a href="http://www.cnblogs.com/xishuai/p/ef7-console-debug-sql.html">EntityFramework 7 如何檢視執行的 SQL 代碼？</a>
<a href="http://www.cnblogs.com/xishuai/p/ef7-orderby-thenby-skip-take-math.html">EntityFramework 7 OrderBy Skip Take－計算排序分頁 SQL 翻譯</a>
<a href="http://www.cnblogs.com/xishuai/p/ef7-linq-join-count-longcount-error.html">EntityFramework 7 Join Count LongCount 奇怪問題</a>
<a href="http://www.cnblogs.com/xishuai/p/ef7-linq-left-join-where-select-error.html">EntityFramework 7 Left Join Where Select 奇怪問題</a>
<a href="http://www.cnblogs.com/xishuai/p/ef7-linq-left-join-where-is-error.html">EntityFramework 7 Left Join Where is error(Test record)</a>
<a href="http://www.cnblogs.com/xishuai/p/ef7-linq-contains-in-error.html">EntityFramework 7 Linq Contains In 奇怪問題</a>
...
上面這些 EF7 問題，都是項目應用中所遇到的，而且是最最普通的問題。通過之前 EF7 Migration 的事件，我自己在解決上面問題中，對于每一個問題，給自己的解決時間為最多半天，如果自己在半天時間内解決不了，那就換一種思路，或者用另外一種方式去實作，達到同樣的效果即可，是以對于上面每一個問題，我都沒有像 EF7 Migration 一樣，陷在裡面過，當然有的解決了，有的沒有解決，比較好的是，可以用另一種方式實作同樣的效果。
這個很無奈，但通過這件事你會發現除這件事之外的很多東西，比如，因為開源，因為社群，你可以幹很多事情，如果自己有能力，有時間，你完全可以去檢視 EF7 的源代碼，去幫微軟解決問題，然後随意的和大洋彼岸寫 C# 最好的程式員交流，當然能幹這些的前提條件很多。
其實這些問題最後确診為“Bug”，就緻使我對使用 EF7 産生了一些動搖，畢竟她現在還處在 Beta 階段，她還年輕，需要時間成長，而我卻沒有時間陪她、等她，這也許是我和她之間的一種無奈吧。
ASP.NET 5 之前的名字叫 ASP.NET vNext，其實我對她就像是與鄰班的女同學，見過幾面，卻不怎麼了解。對于 ASP.NET 5，說白了，我頂多是做了幾個 Demo，并沒有用于生産環境，從 ASP.NET 5 的目錄結構或者其他文章的運作機制介紹中，你就可以看出 ASP.NET 5 這次的改變是翻天覆地的，但簡單的 Demo 說明不了什麼問題，其實在現有的 ASP.NET 5 項目中，我也寫了不少的代碼，但都局限于 Controller 和 View 的使用，對于這塊，你可以像使用之前 MVC 版本一樣，在這部分中，你能體會到它的改變很少，最多你會發現，在 Views 目錄下居然沒有了 Web.config，除了 Controller 和 View，在 ASP.NET 5 中，我寫代碼最多的地方就是 MapRoute 路由配置了，這個不得不說非常強大，寫起來也非常的爽，詳細内容後面再說。
關于 ASP.NET 5，我隻紀錄一點，昨天進行 ASP.NET 5 項目的身份驗證開發，也就是類似之前 MVC 的 <code>FormsAuthentication.SetAuthCookie</code> 操作，你會發現在 ASP.NET 5 中，沒有了這段代碼，身份驗證操作采用類似于 Owin 形式的，但這個我沒接觸過，是以不是很了解，關于這個問題，我給自己一天的時間去解決，或者做出一個可以運作的 IdentityDemo，結果呢？我想你已經猜到了，沒有完成。
AccountController：
ConfigureServices：
這隻是示例項目中的部分代碼，除了 ConfigureServices 中的這部分的配置，其實還有 <code>services.AddIdentity<IdentityUser>();</code>，<code>app.UseIdentity();</code> 等等，到現在我都不明白這其中的差別，或者所不同的作用，在之前的 MVC 版本中，我們一般在 Web.config 中進行下面配置：
而在 ASP.NET 5 中沒有了 Web.config，哪該怎麼進行配置？MusicStore 中并沒有這部分的實作，找資料後發現，要這樣進行配置：
project.json 配置：
Security 類似于關聯賬戶登入，比如你可以在 ASP.NET 5 中，增加外部賬戶驗證（Google、Facebook 賬戶等等），那 <code>Microsoft.AspNet.Identity.EntityFramework</code> 是什麼？身份驗證怎麼和 EF 扯到一起了，這個是 ASP.NET 5 中新增的一個功能，你可以進行配置身份驗證的 DbContext，就比如上面 ConfigureServices 中的配置代碼，然後綁定之後，你可以很友善的進行身份驗證操作，比如 Login、Register、Manage 和 LogOff 等等，找到一篇示例說明：
<a href="https://github.com/aspnet/Identity/wiki/Using-Identity-in-ASP.NET-applications">Using Identity in ASP.NET applications</a>
越扯越多了，這部分内容，可以另外寫篇博文說明，其實最後我想要的功能是不綁定 DbContext，在 ASP.NET 5 項目中，隻進行判斷操作，身份驗證在另外服務中進行，然後在本項目中可以實作類似 <code>FormsAuthentication.SetAuthCookie</code> 操作就可以了，但最後做了幾個 Demo 都不能實作，規定的一天時間，已經用完了，是以。。。
VS2015 提供了 ASP.NET 5 項目的兩個模版，你如果仔細看，在其模版圖示上面有個“vNext”的字樣，這是和其他模版所不一樣的地方，之前有提到過，ASP.NET 5 Web 和 ASP.NET 5 Class Library 隻能互相引用，其他版本的項目或類庫不能引用或被引用，這種“隔離”讓我多了一份“憂慮”。
除了上面的幾個問題，其實 ASP.NET 5 在應用中還有很多未知的問題，隻不過現在還沒遇到罷了，不是說這些問題不能解決，而是說解決這些問題需要時間，當然，如果你有充足的時間，那可以随意的去”折騰“，但公司畢竟不是科學院，做産品也不是搞科研，沒有那麼多的時間去研究。是以，對于我來說，比如身份驗證的實作，我隻給自己一天的時間，如果解決不了，那就考慮其他方式，但對于之後的開發，我覺得再這樣下去，項目幾個月也開發不完，畢竟未知的東西需要時間進行探索，而這就是技術時間成本，是以開發模式需要調整，是以。。。
在寂寞的長巷，我們見了最後一面，你說散就散，我也不想再和你争辯，誰能阻擋新的重逢，忘不了你的錯，忘不了你的好，忘不了雨中的散步，也忘不了那風裡的擁抱。。。－陶喆《忘不了》
昨天思考了一晚上，終于做出了抉擇：抛棄 ASP.NET 5 和 EF7，然後今天早上花了大概半天的時間，去遷移現在用 ASP.NET 5 和 EF7 實作的代碼，然後換做 ASP.NET MVC 5 和 EF6 去實作，其實決定和遷移的過程中，内心是沉重的，因為自己沒有堅持下來，包括今天晚上寫這篇博文，我的心情也是複雜的，但沒辦法，我覺得這個無奈的決定，對我來說，是最好的選擇，咳咳，說的有點像分手的感覺，打住！
在遷移代碼的過程中，和 ASP.NET MVC 5 和 EF6 實作對比後，發現原來 ASP.NET 5 和 EF7 也是如此的美好，下面紀錄一下自己記得的幾點：
project.json 程式包管理的好處：在 ASP.NET 5 類型的項目中，添加程式包的引用非常簡單，隻需要在 project.json 的 dependencies 中，寫對應的程式包名稱就行了，如果删除操作，直接 Control+X 就可以了，而在非 ASP.NET 5 項目中，你需要 packages.config 進行配置管理，更重要的一點，比如針對 EF 的單元測試項目，那你需要在此項目中添加 EF 的引用，然後還需要在 app.config 中，進行連結配置，而在 ASP.NET 5 項目中，隻需要添加需要單元測試的項目即可，因為它會自動加載所依賴項。
EF7 Linq 的強大：這個我也不知道是不是 EF Linq 的問題，就是在編寫 Linq 代碼的時候，一般會有一個 Select 操作，我們一般會在裡面動态拼接 DTO 對象，但有時候我們也會加一些判斷，或者字元串轉化操作，比如 <code>DateFormat ＝ DateAdd.ToString("yyyy-MM-dd HH:mm")</code>，這個操作在 EF7 中是可以的，但在 EF6 中卻報一個類似“表達式不支援 ToString”的異常。
MapRoute 的強大：這個深有體會，因為原來在 ASP.NET 5 中寫的路由配置代碼，居然在 ASP.NET MVC 5 中報錯了，比如下面一段路由配置：
這段代碼會在 ASP.NET MVC 5 中，報無法識别"?"的異常，如果對于參數操作，我們一般會進行這樣配置： <code>page = UrlParameter.Optional</code>，還有一點是，在 ASP.NET MVC 5 中，無法識别 {action}（這個花了很多時間去相容解決，有時間再紀錄下），而在 ASP.NET 5 中，卻是可以的。
幸好的支援：我在 ASP.NET 5 中，使用了一些 C# 6.0 的特性，使用最多的是引用靜态類和字元串變量拼接，遷移之前，我還擔心會不支援，要不然的話，就需要改一大堆的代碼。還好沒什麼問題。
不記得了。
對于 EF7 來說，自己花了太多時間和她“糾纏”，對于 ASP.NET 5 來說，自己對她是一種“無助”，這些都需要時間去完善，畢竟她們還是那麼的年輕，也希望園友們可以多多“折騰”她們，然後把一些實用的心得分享出來，有時候你會發現，當搜尋一個問題，如果找到的話，那是驚喜的感覺，如果沒有找到的話，那是一種絕望的感覺，社群需要分享。
對于我自己來說，這次失敗的“抉擇”，總結一下原因：
能力有限；
時間有限；
資料有限。
本文轉自田園裡的蟋蟀部落格園部落格，原文連結：http://www.cnblogs.com/xishuai/p/asp-net-5-and-ef7.html，如需轉載請自行聯系原作者