实体框架是否适合我们的情况？

Question

我的小组做了些什么..。

我在一家相当大的保险公司的开发团队工作。我的团队的责任主要是为我们的员工创建应用程序。如跟踪系统，调度应用程序，联系目录等。

当然，我们有大量的“共享数据”，所有应用程序通常都会引用这些数据。比如州，员工，以及一系列与我们特定业务相关的元素(代理商、业务线、评级公司等)。目前，我们有一组通用代码，所有应用程序都可以利用这些代码检索大部分公共数据。

我们所遇到的大多数请求要么需要对当前数据库对象进行调整，要么需要创建许多新的数据库对象。我们的组相当小，但是我们仍然可能有3-4组数据库更改在任何给定的时间通过我们的变更管理系统，并且，根据优先级，一些更新的更改可能会在其他更改的生产过程中跳过。

我理解EFL带来的所有好处，但考虑到我们的设置，我也有几点担心:由于有共享数据的元素，为整个数据库(包含所有不同应用程序的所有对象)建立一个数据模型似乎是有意义的。这是个安全的假设吗？或者，是否有可能建立独立的数据模型，并让它们相互交互？

最后，我们想要一个名为" Employee“的类，我们希望它能够在任何应用程序中保持不变，所以我们似乎需要创建一个超级数据模型，这样应用程序A都可以访问雇员数据，并且都引用Employee类。除非该类可以坐在GAC DLL中，然后每个数据模型都可以引用.或者，正如我所问的，单独的数据模型可以相互交互。

然后..。如果我们使用一个巨型数据模型，那么让不同的个人对统一的数据模型进行单独的更改，然后通过变更管理系统将其向上移动，会有多大的困难？

我可以看到在筒仓应用程序中使用这种技术的好处.尤其是维护最少的..。但我很难想象，随着大量不同的数据模型维护发生，节省的时间是否还会大量存在.都在同一时间。

如有任何建议，将不胜感激。

Answer 1

至于版本控制，我将告诉您，您已经以不同的形式出现了这个问题，尽管您可能不知道。您有一个数据库，但是有多个项目访问数据，对吗？本质上，现在发生的事情是，由于您(可能)使用SQL在您的每个应用程序中访问您的数据库，所以不管您对数据库做了什么更改，您的项目仍然是编译的。任何真正的破坏变化都会在运行时发生。

通过添加实体数据模型，您只需将应用程序中的这种中断转移到编译时发生的中断。我想我的问题是：“您是如何对数据库更改进行版本化的？”我建议您创建单个实体数据模型，将其打包到程序集中，并在对数据库进行更改时对其进行更改。使用源代码管理提供程序中的分支和合并来管理这些更改是如何在您的开发工作流程中实际发生的。实体框架的新版本在管理合并方面比过去要好得多。

Answer 2

我的经验是:人间地狱。

我们有一个大的核心产品，有许多模块添加到它。给定的客户将有一个核心加上一个或多个模块，而任何客户都将拥有与任何其他模块不同的一组模块。模块可以对DB模式进行更改，通常是对它们自己的表进行更改，但偶尔也会向核心表中添加列。

在此之前，这很简单，您可以更改sql，并随附每个模块的安装说明。没有任何问题(当然，除非它没有正确安装，但这是任何事情的问题)。

我们搬到EF的时候，一点也不好玩。首先，如果对DB进行更改，则相应地更改本地EF。然后，您必须重新构建使用该EF程序集的所有模块和核心--否则会出现错误，或者更糟的是，它无法完全加载模块。(我们发现，您可以使用GAC和策略文件，但是它们很快就会加法，并且在GAC中有很多相同的dll停止工作)

当要进行测试时，您现在必须构建一个EF程序集，该程序集可以查看客户使用的DB，并重新构建所有组件--就像您有一个版本控制系统一样--否则它们都不会加载。

因此，我们从用sql语句编写文本文件到任何DB，再到更新许多不同的EF all，并确保正确安装它们，以及始终重建大量的模块。也许我们可以更好地使用子EF dll，但核心部分是几个Mb，所以我们不想在每个客户站点上同时管理很多这样的东西。

可以在筒仓(您指的是单块)应用程序中节省费用，但在更改DB模式时，您仍然必须管理重构(或者最终推出大量的EF dll)。我可能想再做一次，试着把它做好，但我认为旧的方法是如此的简单和简单，以至于我不知道我为什么要费心。拥有LINQ固然不错，但是编写旧sql并不需要一整天的时间。