EF迁移应该去哪里，我的类库项目或我的ASP.NET项目？ [英] Where should EF Migrations go, my Class Library project or my ASP.NET project?

问题描述

我的解决方案包括：

• FooBarAsp ，一个ASP项目（提供了一个用户界面应用程序）


• FooBar的后，类库（应用程序）


• FooBar.Tests ，测试项目（测试应用程序）

• FooBarAsp, an asp project (provides a UI for the application)
• FooBar, a class library (the application)
• FooBar.Tests, a test project (tests the application)

FooBar的使用EF 6 code首先，它包含了一些车型，并以的DataContext 。 FooBarAsp使用微软的用户验证身份的框架，并有一个 ApplicationDbContext 。这两种情况下按预期发挥好和工作。 Global.asax.cs中应该执行 MigrateDatabaseToLatestVersion （右？）。 FooBar.Tests应该执行 DropCreateDatabaseAlways 并不会在意迁移（右？）。

FooBar uses EF 6 Code First, and contains a number of models, and a DataContext. FooBarAsp uses Microsoft's Identity framework for user authentication, and has an ApplicationDbContext. Both contexts play nice and work as expected. Global.asax.cs should execute MigrateDatabaseToLatestVersion (right?). FooBar.Tests should execute DropCreateDatabaseAlways and won't care about migrations (right?).

我应该在FooBarAsp，或FooBar的EnableMigrations？对于这两种情况下？

在运行FooBar的EnableMigrations（只是踢）之后，我的__MigrationHistory表包含两行InitialCreate，其中一个ContextKey = FooBar.Models.DataContext和其他与ContextKey = FooBarAsp.Models.ApplicationDbContext。于是，他们俩都已经被追踪？如果是这样，（因为我没有启用自动迁移），我是否需要显式运行的两个的 MigrateDatabaseToLatestVersion＆LT; D​​ataContext的＆GT; 和 MigrateDatabaseToLatestVersion＆LT; ApplicationDbContext＆GT; 中的Global.asax.cs

After running EnableMigrations in FooBar (just for kicks), my __MigrationHistory table contains two InitialCreate rows, one with ContextKey=FooBar.Models.DataContext and the other with ContextKey=FooBarAsp.Models.ApplicationDbContext. So they're both being tracked already? If so, (and since I did not enable automatic migrations), do I need to explicitly run both MigrateDatabaseToLatestVersion<DataContext> and MigrateDatabaseToLatestVersion<ApplicationDbContext> in Global.asax.cs?

我为什么不想要移动 ApplicationUser 进入FooBar的和合并 ApplicationDbContext 到的DataContext ？

Why don't I want to move ApplicationUser into FooBar and merge ApplicationDbContext into DataContext?

该股随ASP ApplicationUser 是一个独立的实体（独立的 ApplicationDbContext ，这恰好指向相同的数据库）。 ASP的 ApplicationUser 和身份框架照顾验证，登记，电子邮件验证，登录，注销，密码，密码强度，密码重置，双因素认证，饼干，会话，外部来自像Facebook /谷歌等FooBar的不知道也不关心任何的来源登录。 FooBar的的用户活动的用户名和ASP的 ApplicationUser 活动的用户名。当，我只是仰望Foobar的的用户按用户名，这是谁的登录。所以当我创建一个新的博客（其中博客是一个FooBar的实体），作者是FooBar的的用户（不是 ApplicationUser ）。最终的结果是，FooBar的不是Web /桌面/控制台/ iPhone / Android应用程序。它是任何这些东西可以参考，交互，和提供一种用于用户接口的库。的一点是，FooBar的不被任何这些用户界面的污染或施力。

The stock ApplicationUser that comes with ASP is a separate entity (and separate ApplicationDbContext, which happens to point to the same database). ASP's ApplicationUser and the Identity framework take care of authentication, registration, email verification, login, logout, passwords, password strength, passwords resetting, two factor authentication, cookies, sessions, external login from sources like facebook/google, etc. FooBar doesn't know or care about any of that. FooBar's Users have a UserName, and ASP's ApplicationUsers have a UserName. When a user logs in, I just look up Foobar's User by UserName, and that's who is logged in. So when I create a new Blog (where Blog is a FooBar entity), the author is FooBar's User (not ApplicationUser). The end result is that FooBar is not a Web/Desktop/Console/iPhone/Android application. It's a library that any of those things can reference, interact with, and provide a user interface for. The point is that FooBar is not polluted or biased by any of those user interfaces.

所以我不希望移动 ApplicationUser 进入FooBar的，因为它从Microsoft.AspNet.Identity命名空间的，而FooBar的不知道或关心ASP.NET （WPF或或任何接口恰好是）。

So I don't want to move ApplicationUser into FooBar because it's from the Microsoft.AspNet.Identity namespace, and FooBar doesn't know or care about ASP.NET (or WPF or whatever the interface happens to be).

推荐答案

像约翰在他的评论中说，你可能会被所有的EF code的移动到一个单独的类库提供服务很好。我通常创建Web，域名，数据访问和测试项目的一个新的解决方案，以及他们更加分裂的道路，如果有必要。这给你前面的担忧一些明确的，基本的分离。 Visual Studio的Web项目的模板不提供，因为它的设计是自包含在一个单一的项目。

Like John said in his comment, you might be served well by moving all of your EF code into a separate class library. I typically create Web, Domain, DataAccess, and Test projects for a new solutions, and split them up even more down the road if it's necessary. This gives you some clear, basic separation of concerns up front. The Visual Studio Web project templates don't provide that, as it's designed to be self-contained in a single project.

Visual Studio的网站模板是小项目一个很好的起点，但随着项目的发展很快pretty变得一团糟。其网站（这或多或少是您的presentation层），领域模型和放大器;业务逻辑，并都在同一个项目中的数据访问是不是特别好做法。部分被留下您的用户模型和一个单独的的DbContext 落后于Web应用程序可以更加混乱海事组织，特别是如果你的 ApplicationUser s的要去参加与您的域名类库模型的关系。

Visual Studio's Web template is a good starting point for small projects but it pretty quickly becomes a mess as the project grows. Having the website (which is more or less your presentation layer), domain models & business logic, and data access all in the same project isn't particularly good practice. Partially separating them by leaving your user models and a separate DbContext behind in the web application can be even more confusing IMO, especially if your ApplicationUsers are going to participate in relationships with models from your domain class library.

我会建议将您的 ApplicationUser 到包含您的域模型的类库，并把你的 ApplicationDbContext 和它移动到一个数据访问类库。你可以采取一步，你的两个DbContexts组合成一个没有太多的精力，除非你怀疑该项目将增长足够大，需要多个`DbContexts。在这一点上，它变得非常明显的在您的迁移应该活。除非你试图抽象它拿走，你的初始化器将始终走在应用程序，你的情况是FooBarAsp，所以你正确的，Global.asax中是设置，最多的地方。

I would suggest moving your ApplicationUser into the class library that contains your domain models, and take your ApplicationDbContext and move it into a DataAccess class library. You can take that one step further and combine your two DbContexts into one without much effort, unless you suspect that the project will grow large enough to require multiple `DbContexts. At that point, it becomes very apparent where your Migrations should live. Unless you're trying to abstract it away, your Initializer will always go in the application, which in your case is FooBarAsp, so you're correct that Global.asax is the place to set that up.

的然而的，如果这听起来吸引力给你，你想保持你的项目结构，因为它目前是，这是我认为你最好关闭配置迁移为的DbContext S表示一致的缘故。在这一点上，你有一组迁移的Web项目（FooBarAsp）为 ApplicationDbContext 从继承 IdentityDbContext ，另一套，在你的类库（FooBar的）居住迁移。双方都需要在你的web项目的Global.asax.cs初始化。

However, if this sounds unappealing to you and you'd like to keep your project structure as it currently is, it's my opinion that you would be best off configuring migrations for both DbContexts for consistency's sake. At that point, You'd have a set of Migrations in your web project (FooBarAsp) for the ApplicationDbContext that inherits from IdentityDbContext and another set of migrations that resided in your class library (FooBar). Both would need initializers in the Global.asax.cs of your web project.

基于OP的更新编辑：我能看到你从你的愿望，以保持ASP.NET相关引用了您的域层的到来。它基本上是不可能保持这种从没有为你做两个分手了你的用户模型发生。 <一href=\"http://stackoverflow.com/questions/20011680/best-practices-for-integrating-asp-net-identity-do-they-exist\">This是我问的时候VS2013仍然pre-RTM ，并从来没有得到一个满意的答案，因为它目前还无法有一个User模型，与身份的作品并不在某些ASP.NET相关的拉组件。然而，在有些类似的情况，在 DbGeography 类型可以是一个非常有用的类型在你的领域层包括但它不可能使用它没有实体框架的相关组件拉。它真的可以归结为权衡的利弊和采摘的时间和地点应用设计模式的两个较小evils-是务实的。

Edit based on OP's update: I can see where you're coming from in your desire to keep ASP.NET related references out of your domain layer. It's basically impossible to keep this from happening without splitting up your user models in two as you've done. This is something I asked about when VS2013 was still pre-RTM and never got a satisfactory answer because it's currently not possible to have an User model that works with Identity that doesn't pull in some ASP.NET related assemblies. However, in a somewhat analogous situation, the DbGeography type can be a very useful type to include in your domain layer, but it's impossible to use it without pulling in Entity Framework related assemblies. It really comes down to weighing the pros and cons and picking the lesser of two evils- be pragmatic in when and where you apply design patterns.

这是说，如果你想保持的DbContext 在你的web应用程序独立和 ApplicationUser ，我建议在实际上应用用户可拉出所有不必要的字段，只使用IdentityUser类本身，而不是它的子类，因为你会纯粹是使用它的身份验证和授权。然而，我的认为的你仍然需要使能对环境迁移和考虑如何使用的每个数据库的多个环境与EF6 ，这是不可能的EF5。

That said, if you do want to keep the DbContexts separate and the ApplicationUser in your web application, I'd suggest pulling out all the extraneous fields from the application user- in fact, just use the IdentityUser class itself instead of subclassing it since you'll be using it purely for authentication and authorization. However, I believe you'll still need to enable Migrations for both contexts and look into how to use multiple contexts per database with EF6, which wasn't possible in EF5.

这篇关于EF迁移应该去哪里，我的类库项目或我的ASP.NET项目？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！