我应该为每个表创建一个ADO.NET实体数据模型，还是为整个数据库创建一个？

Question

你应该为每个表使用一个ADO.NET实体数据模型吗？ 或者一个用于整个数据库，其中关系也被路由，等等......

Answer 1

为整个数据库做。 如果为每个表创建数据模型，则无法导航关系。

如果您正在使用像Subversion这样的结帐/合并源代码控制，请注意设计人员将XML扩展到Subversion努力合并它的程度。 在这种情况下，您通常每次都必须重新生成整个模型或手动合并。

Answer 2

我为相关表使用实体数据模型。 根据数据库的大小，如果少于大约20或25个表，我将只创建一个模型。 为每个表创建单独的模型有点贵，因为每个模型都有一个要创建的EntityConnection对象。

如果我有5到15个表，我发现我可以很好地维护模型。 我的主要决定因素是功能。 我建造工程应用程序，例如我有大约6个结构钢组件表。 它们都在一个模型中。 它们共享通用的工程属性，因此更容易重用特定于操作这些属性的代码。

这意味着我可以实例化模型，创建对象，在公共代码文件中操作/组织这些对象。 任何需要传回数据库的更改都可以非常有效地完成。

底线是确定您对底层对象的需求和使用频率。 如果您要不断更新一个或两个表，那么在该模型中包含30个其他非相关表是没有意义的。 在频繁使用少量表的情况下，创建这些对象的集合，操作集合并在适当的时间更新数据库可能是有意义的。

内存操作比磁盘I / O便宜得多。 这只是我对框架的看法，绝不是我的专家。

Answer 3

一个用于您的整个数据库或至少您将使用的表...

如果你有大量的表，你可以将它们分解为模式或其他一些分类方式，但我会说这个想法从来就不是每个表的数据模型......

Answer 4

我将独立于数据库模式设计数据的概念/对象模型，然后创建最佳地将概念模型与数据库模式相关联的映射。 它可能使用大多数（如果不是全部）表。 如果您希望与表进行一对一映射，则可能需要考虑使用LINQ-to-SQL，因为它更容易使用。

Answer 5

除了上面的答案，请记住，EF模型实际上处于概念层面。 它不需要与数据库的结构有任何关系，当然也不需要代表整个数据库。

Answer 6

我想如果你有大型数据库，那么你需要对数据库表进行分类。 但是你必须为每个表创建一个类，这是ado.net实体框架的主要要求。

更新数据库时，您可以使用更新数据模型。

首先设计数据库然后创建ado.net实体模型。