你是否应该为每个表使用一个 ADO.NET 实体数据模型？还是为整个数据库使用一个，其中关系也被路由等等...
我应该为每个表创建一个ADO.NET实体数据模型，还是为整个数据库创建一个？
4
- Matt
6个回答
6
为整个数据库做。如果你为每个表制作数据模型，你将无法获得浏览关系的好处。
如果您正在使用类似Subversion的检出/合并源代码控制，请注意设计师会对XML进行修改，以至于Subversion很难合并它。在这种情况下，通常您需要每次重新生成整个模型或手动合并。
- Hans Malherbe
2
我在相关表格中使用实体数据模型。根据您的数据库大小，如果少于大约20或25个表，则只需创建一个模型。为每个表创建单独的模型有点昂贵，因为每个模型都需要创建一个EntityConnection对象。
我发现如果有5到15个表，我可以相当好地维护这些模型。我的主要决定因素是功能性。我构建工程应用程序，例如我有约6个结构钢件表。它们都在一个模型中。它们共享常见的工程属性，因此更容易重用特定于操作这些属性的代码。
这意味着我可以实例化模型，创建对象，在一个通用代码文件中操纵/组织这些对象。需要传播回数据库的任何更改都可以非常有效地完成。
关键是确定您对基础对象的需求和使用频率。如果您将不断更新一两个表，则在该模型中拥有30个其他非相关表并不合理。在这种情况下，如果经常使用少量表格，则创建这些对象的集合，操纵集合并在适当的时候更新数据库可能是有意义的。
内存操作比磁盘I/O要便宜得多。这只是我的框架观点，我并不是专家。
我发现如果有5到15个表，我可以相当好地维护这些模型。我的主要决定因素是功能性。我构建工程应用程序，例如我有约6个结构钢件表。它们都在一个模型中。它们共享常见的工程属性，因此更容易重用特定于操作这些属性的代码。
这意味着我可以实例化模型，创建对象，在一个通用代码文件中操纵/组织这些对象。需要传播回数据库的任何更改都可以非常有效地完成。
关键是确定您对基础对象的需求和使用频率。如果您将不断更新一两个表，则在该模型中拥有30个其他非相关表并不合理。在这种情况下，如果经常使用少量表格，则创建这些对象的集合，操纵集合并在适当的时候更新数据库可能是有意义的。
内存操作比磁盘I/O要便宜得多。这只是我的框架观点，我并不是专家。
- John Cuckaroo
1
针对整个数据库或至少你将使用的表...
如果你有大量的表，你可以将它们分成模式或其他分类方式，但我认为这个想法从来不是每个表一个数据模型...
- bytebender
1
我会独立设计数据的概念/对象模型，而不考虑数据库架构，然后创建最佳映射以将概念模型与数据库架构相关联。这可能会使用大部分（如果不是全部）表格。如果您想要一对一的表格映射，您可以考虑使用LINQ-to-SQL，因为它更容易使用。
- Mark Cidade
1
除了上面的答案之外，还要记住EF模型实际上是在概念层面上。它不需要与您的数据库结构有任何关系，当然也不需要代表整个数据库。
- John Saunders
-1
我认为如果您拥有大型数据库，则需要对数据库表进行分类。但是您必须为每个表创建一个类，这是ado.net实体框架的主要要求。
当您更新数据库时，可以通过更新数据模型来完成。
首先设计您的数据库，然后创建ado.net实体模型。
- Jalpesh Vadgama
1
为每个表创建一个类并不是ADO.NET EF的要求。实际上，一个实体可以映射到多个表。 - Mark Cidade
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接