4

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

4

6 回答 6

6

对整个数据库执行此操作。如果您为每个表创建数据模型，您将无法获得导航关系的好处。

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

于 2009-06-22T18:38:21.883 回答
2

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

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

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

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

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

于 2009-06-22T18:55:55.787 回答
1

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

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

于 2009-06-22T18:36:37.083 回答
1

In addition to the answers above, keep in mind that an EF model is actually at a conceptual level. It doesn't need to have anything to do with the structure of your database, and certainly doesn't need to represent the entire database.

于 2009-06-22T20:31:11.700 回答
1

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

于 2009-06-22T18:42:07.633 回答
-1

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

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

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

于 2009-06-22T18:41:52.707 回答