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，如需转载请自行联系原作者