ASP.NET 5+EntityFramework 7

爱与恨的抉择: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+EntityFramework 7

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

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

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

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

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

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

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

ASP.NET 5+EntityFramework 7

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

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

ASP.NET 5 的无助

ASP.NET 5+EntityFramework 7

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 等等,找到一篇示例说明:

越扯越多了,这部分内容,可以另外写篇博文说明,其实最后我想要的功能是不绑定 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+EntityFramework 7

在寂寞的长巷,我们见了最后一面,你说散就散,我也不想再和你争辩,谁能阻挡新的重逢,忘不了你的错,忘不了你的好,忘不了雨中的散步,也忘不了那风里的拥抱。。。-陶喆《忘不了》

昨天思考了一晚上,终于做出了抉择:抛弃 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. 资料有限。
上一篇:爱与恨的抉择:ASP.NET 5+EntityFramework 7


下一篇:EntityFramework 7 Join Count LongCount 奇怪问题(已修复)