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

Question

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

Answer 1

对整个数据库都这样做。如果你为每个表格创建一个数据模型，你将不会享有导航关系的好处。

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

Answer 2

一为您的整个数据库，或者至少你会使用表...

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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