ASP.NET 5＋EntityFramework 7

爱与恨的抉择：ASP.NET 5＋EntityFramework 7

 

• EF7 的纠缠
• ASP.NET 5 的无助
• 忘不了你的好

一开始列出的这个博文大纲，让我想到了很久之前的一篇博文：恋爱虽易，相处不易：当EntityFramework爱上AutoMapper，只不过这次的剧情换主角了，而且与 EF 和 AutoMapper 爱情故事不同的是，这次是个悲剧。

对 ASP.NET 5 和 EF7 的感情，从她俩一出生，我就不可自拔的爱上她们了，不要嫌哥多情，有“情”，就是任性。

从一开始的一见钟情，到慢慢的深入了解，再到最后的抉择与无奈，不管结局如何如何，其实这个过程，已经让我们彼此学到了很多，也成长了很多。

EF7 的纠缠

前段时间，重写之前的一个项目，选择的是用 ASP.NET 5＋EF7 进行开发，因为我自己很喜欢 EF，所以一开始就先研究的 EF7，当看到 Code First Only，以及跨平台的支持（和我关系不大）等等，非常的激动，记得当时还纪录了一篇博文：EF7 Code First Only－所引发的一些“臆想”，有人会说，对于 EF 的开发模式，EF7 的功能又不是增加，而是减少了（Only），有必要这么大惊小怪吗？当然表面上来说，确实没有什么惊奇的地方，但自己深入一想，Only 关键字，所传递的一些信息却是另一层面的东西，那篇博文中已经写的很详细了，这边就不啰嗦了。

对于 EF7 的项目应用，我自己是充满信心的，不管遇到什么问题，我也都想尽办法去解决，无奈的是网上资料太少，谷歌搜索一些 EF7 问题关键词，基本上找不到对应的解决方案，所以有些东西只能自己去摸索，去实践，但这样也会造成，往往一个很简单的问题，自己却想的很复杂，最后就不知不觉的陷在里面，而且越是解决不了，自己就越想解决，然后就陷入一个恶性循环，最后呢？这个问题还是没有解决，这样所造成的结果是什么呢？很简单，宝贵的时间被浪费了，没办法，这也是新技术所应用的成本。

我记得有一个 EF7 Migration 的问题，这个问题大概花了我两三天的时间，是的，两三天的时间啊，一直在解决这个问题，最后呢？很显然，没有解决，而且之后的几天一直在郁闷，压抑的感觉越来越强烈，当一个问题存在你心中很久很久，你就越想解决它，这个想法也就会变的越来越强烈，所以你需要你个发泄点，什么呢？就是写博文。转移注意力，也算是一种吐槽，就纪录了一篇博文：

• EntityFramework 7 开发纪录

这篇博文前面部分是一些 EF7 的简单使用，比如链接与实体映射配置等，当然用过之后，你会发现和 EF 的其他版本差别很大，不可否认，非常强大，也更加“人性化”，比如最爱的：OneToOne、OneToMany 和 ManyToOne，简单、直接、明了。博文的后半部分主要纪录我遇到的 EF7 Migration 问题，当然只是一个纪录，没有说明其解决方式，当时纪录的目的也更多的是一种吐槽，或者自我发泄，但没想到有一位园友 JeffreyWu，回复中贴出的一个参考链接，打开了自己的一扇窗，真心非常感谢他，而且当时的心情真是描述不出来，就像乌云之后的晴天，压抑自己的一个问题，终于被解决了，那种感觉真是比中 500W 彩票的感觉还要好。

其实你发现，EF7 Migration 的问题解决很简单，就是换一种方法：使用 KVM 进行命令操作，而我那几天时间却一直扑在：怎么使用 Package Manager Console 进行 EF7 Migration 操作？而且一直陷在里面，最后却解决不了。所以通过这件事，我自己也收获了一点，那就是如何解决问题？如果一个问题在一个场景中自己始终解决不了，不妨跳出这个场景，换一种思路去解决，不经意的一瞬间，也许这个问题就可以解决了。当然收获的最重要一点是：有问题，写博文，抛出问题，之后零零散散纪录了一些：

• EntityFramework 7 smallint short 奇怪问题（已解决）
• EntityFramework 7 如何查看执行的 SQL 代码？
• EntityFramework 7 OrderBy Skip Take－计算排序分页 SQL 翻译
• EntityFramework 7 Join Count LongCount 奇怪问题
• EntityFramework 7 Left Join Where Select 奇怪问题
• EntityFramework 7 Left Join Where is error(Test record)
• EntityFramework 7 Linq Contains In 奇怪问题
• ...

上面这些 EF7 问题，都是项目应用中所遇到的，而且是最最普通的问题。通过之前 EF7 Migration 的事件，我自己在解决上面问题中，对于每一个问题，给自己的解决时间为最多半天，如果自己在半天时间内解决不了，那就换一种思路，或者用另外一种方式去实现，达到同样的效果即可，所以对于上面每一个问题，我都没有像 EF7 Migration 一样，陷在里面过，当然有的解决了，有的没有解决，比较好的是，可以用另一种方式实现同样的效果。

在博文中，有园友说可以把问题提交给：EntityFramework 7 Issues，然后我也顺便提交了几个，当时看到 issues 中那几百个问题，而且大部分都是 Open 状态，Closed 的很少，对于提交的问题，我的想法是希望自己的写法有问题，而不是 EF7 本身的问题，因为我项目正在使用它，我自己的问题可以解决，如果是它的问题，要等它解决，这就需要时间，不知道何年何月，但事实却是，提交的几个问题都是 Bug：

这个很无奈，但通过这件事你会发现除这件事之外的很多东西，比如，因为开源，因为社区，你可以干很多事情，如果自己有能力，有时间，你完全可以去查看 EF7 的源代码，去帮微软解决问题，然后随意的和大洋彼岸写 C# 最好的程序员交流，当然能干这些的前提条件很多。

其实这些问题最后确诊为“Bug”，就致使我对使用 EF7 产生了一些动摇，毕竟她现在还处在 Beta 阶段，她还年轻，需要时间成长，而我却没有时间陪她、等她，这也许是我和她之间的一种无奈吧。

ASP.NET 5 的无助

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 的 FormsAuthentication.SetAuthCookie 操作，你会发现在 ASP.NET 5 中，没有了这段代码，身份验证操作采用类似于 Owin 形式的，但这个我没接触过，所以不是很了解，关于这个问题，我给自己一天的时间去解决，或者做出一个可以运行的 IdentityDemo，结果呢？我想你已经猜到了，没有完成。

关于 ASP.NET 5 的学习，微软提供了一个 ASP.NET 5 版本的 MusicStore 项目，对于学习资料很少的 ASP.NET 5 来说，这是相当宝贵的，关于身份验证的实现，我当时也希望可以从这个项目中得到一些启发，但遗憾的是没有找到我所需要的，我稍微贴一下这部分的实现代码。

AccountController：

[Authorize]
public class AccountController : Controller
{
    public AccountController(UserManager<ApplicationUser> userManager, SignInManager<ApplicationUser> signInManager)
    {
        UserManager = userManager;
        SignInManager = signInManager;
    }

    public UserManager<ApplicationUser> UserManager { get; private set; }
    public SignInManager<ApplicationUser> SignInManager { get; private set; }

    // GET: /Account/Login
    [HttpGet]
    [AllowAnonymous]
    public IActionResult Login(string returnUrl = null)
    {
        ViewBag.ReturnUrl = returnUrl;
        return View();
    }

    //
    // POST: /Account/Login
    [HttpPost]
    [AllowAnonymous]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null)
    {
        if (ModelState.IsValid)
        {
            var signInStatus = await SignInManager.PasswordSignInAsync(model.UserName, model.Password, model.RememberMe, shouldLockout: false);
            switch (signInStatus)
            {
                case SignInStatus.Success:
                    return RedirectToLocal(returnUrl);
                case SignInStatus.Failure:
                default:
                    ModelState.AddModelError("", "Invalid username or password.");
                    return View(model);
            }
        }

        // If we got this far, something failed, redisplay form
        return View(model);
    }
}

ConfigureServices：

// Add Identity services to the services container.
services.AddDefaultIdentity<ApplicationDbContext, ApplicationUser, IdentityRole>(Configuration);

这只是示例项目中的部分代码，除了 ConfigureServices 中的这部分的配置，其实还有 services.AddIdentity<IdentityUser>();，app.UseIdentity(); 等等，到现在我都不明白这其中的区别，或者所不同的作用，在之前的 MVC 版本中，我们一般在 Web.config 中进行下面配置：

<system.web>
  <authentication mode="Forms">
    <forms name=".DottextCookie" loginUrl="~/Account/Login" protection="All" domain=".demo.com" protection="All" timeout="43200" path="/" />
  </authentication>
  <compilation debug="true" targetFramework="4.5.3" />
  <httpRuntime />
</system.web>

而在 ASP.NET 5 中没有了 Web.config，哪该怎么进行配置？MusicStore 中并没有这部分的实现，找资料后发现，要这样进行配置：

app.UseCookieAuthentication((cookieOptions) =>
{
    cookieOptions.AuthenticationType = ClaimsIdentityOptions.DefaultSecurityStampClaimType;
    cookieOptions.AuthenticationMode = AuthenticationMode.Active;
    cookieOptions.CookieHttpOnly = true;
    cookieOptions.CookieName = ".DottextCookie";
    cookieOptions.LoginPath = new PathString("/Account/Login");
    cookieOptions.CookieDomain = ".demo.com";
}, "AccountAuthorize");

project.json 配置：

"dependencies": {
    "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta1",
    "Microsoft.AspNet.Identity": "3.0.0-beta1",
    "Microsoft.AspNet.Security": "1.0.0-beta1",
    "Microsoft.AspNet.Security.Cookies": "1.0.0-beta1"
}

Security 类似于关联账户登录，比如你可以在 ASP.NET 5 中，增加外部账户验证（Google、Facebook 账户等等），那 Microsoft.AspNet.Identity.EntityFramework 是什么？身份验证怎么和 EF 扯到一起了，这个是 ASP.NET 5 中新增的一个功能，你可以进行配置身份验证的 DbContext，就比如上面 ConfigureServices 中的配置代码，然后绑定之后，你可以很方便的进行身份验证操作，比如 Login、Register、Manage 和 LogOff 等等，找到一篇示例说明：

• Using Identity in ASP.NET applications

越扯越多了，这部分内容，可以另外写篇博文说明，其实最后我想要的功能是不绑定 DbContext，在 ASP.NET 5 项目中，只进行判断操作，身份验证在另外服务中进行，然后在本项目中可以实现类似 FormsAuthentication.SetAuthCookie 操作就可以了，但最后做了几个 Demo 都不能实现，规定的一天时间，已经用完了，所以。。。

还有一个问题是如何在 ASP.NET 5 项目中添加 Web 引用，比如 WCF，但你发现在 Web 项目或是类库项目，并没有“Add Web Reference”这个选项，比如这个帖子：Add Web Service Reference in VS 2015，没人回答，搜索之类的关键词，如果有回答，大部分是：no，那如果不支持的话，可以换一种思路去解决，比如使用 WebAPI，当然现在也比较流行这个，但这就会造成一个重写成本，你需要额外进行考虑。

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 也是如此的美好，下面纪录一下自己记得的几点：

1. project.json 程序包管理的好处：在 ASP.NET 5 类型的项目中，添加程序包的引用非常简单，只需要在 project.json 的 dependencies 中，写对应的程序包名称就行了，如果删除操作，直接 Control+X 就可以了，而在非 ASP.NET 5 项目中，你需要 packages.config 进行配置管理，更重要的一点，比如针对 EF 的单元测试项目，那你需要在此项目中添加 EF 的引用，然后还需要在 app.config 中，进行链接配置，而在 ASP.NET 5 项目中，只需要添加需要单元测试的项目即可，因为它会自动加载所依赖项。
2. EF7 Linq 的强大：这个我也不知道是不是 EF Linq 的问题，就是在编写 Linq 代码的时候，一般会有一个 Select 操作，我们一般会在里面动态拼接 DTO 对象，但有时候我们也会加一些判断，或者字符串转化操作，比如 DateFormat ＝ DateAdd.ToString("yyyy-MM-dd HH:mm")，这个操作在 EF7 中是可以的，但在 EF6 中却报一个类似“表达式不支持 ToString”的异常。
3. EF7 与 AutoMapper 结合的强大：这个主要是对 .Project().To<SimpleDTO>() 的操作，如果这样使用，会不支持映射的 ResolveUsing 配置，记得还纪录过一篇博文：AutoMapper Project To not support ResolveUsing，虽然不支持 ResolveUsing，但在博文中，提到了一种替换方法，比如 ForMember(dto => dto.Name, opt => opt.MapFrom(ol => NameCustomResolver(ol)))，就是自行写 Resolver 转换方法，但这个配置却在 EF6 中报错，而在 EF7 中却是可以的。

4. MapRoute 的强大：这个深有体会，因为原来在 ASP.NET 5 中写的路由配置代码，居然在 ASP.NET MVC 5 中报错了，比如下面一段路由配置：

   routes.MapRoute(
       name: "demo_type",
       template: "n/{typeName}/{page?}",
       defaults: new { controller = "Home", action = "Index" });

   这段代码会在 ASP.NET MVC 5 中，报无法识别"?"的异常，如果对于参数操作，我们一般会进行这样配置： page = UrlParameter.Optional，还有一点是，在 ASP.NET MVC 5 中，无法识别 {action}（这个花了很多时间去兼容解决，有时间再纪录下），而在 ASP.NET 5 中，却是可以的。

5. 幸好的支持：我在 ASP.NET 5 中，使用了一些 C# 6.0 的特性，使用最多的是引用静态类和字符串变量拼接，迁移之前，我还担心会不支持，要不然的话，就需要改一大堆的代码。还好没什么问题。

6. 不记得了。

对于 EF7 来说，自己花了太多时间和她“纠缠”，对于 ASP.NET 5 来说，自己对她是一种“无助”，这些都需要时间去完善，毕竟她们还是那么的年轻，也希望园友们可以多多“折腾”她们，然后把一些实用的心得分享出来，有时候你会发现，当搜索一个问题，如果找到的话，那是惊喜的感觉，如果没有找到的话，那是一种绝望的感觉，社区需要分享。

对于我自己来说，这次失败的“抉择”，总结一下原因：

1. 能力有限；
2. 时间有限；
3. 资料有限。

作者：田园里的蟋蟀 
出处：http://www.cnblogs.com/xishuai/