您是否应该为每个表使用一个ADO.NET实体数据模型？或者一个用于整个数据库，其中关系也被路由，等等......
答案 0 :(得分：5)
为整个数据库执行此操作。如果为每个表创建数据模型，则无法导航关系。
如果您正在使用像Subversion这样的结帐/合并源代码控制，请注意设计人员将XML扩展到Subversion努力合并它的程度。在这种情况下，您通常必须每次都重新生成整个模型或手动合并。
答案 1 :(得分：2)
我为相关表使用实体数据模型。根据数据库的大小，如果少于大约20或25个表，我将只创建一个模型。为每个表创建单独的模型有点贵，因为每个模型都有一个要创建的EntityConnection对象。
如果我有5到15个表，我发现我可以很好地维护模型。我的主要决定因素是功能。我建造工程应用程序，例如我有大约6个结构钢组件表。它们都在一个模型中。它们共享通用的工程属性，因此可以更轻松地重用特定于操作这些属性的代码。
这意味着我可以实例化模型，创建对象，在公共代码文件中操作/组织这些对象。任何需要传回数据库的更改都可以非常有效地完成。
底线是确定您对底层对象的需求和使用频率。如果您要不断更新一个或两个表，那么在该模型中包含30个其他非相关表是没有意义的。在频繁使用少量表的情况下，创建这些对象的集合，操作集合并在适当的时间更新数据库可能是有意义的。
内存操作比磁盘I / O便宜得多。这只是我对框架的看法，绝不是我的专家。
答案 2 :(得分：1)
一个用于整个数据库，或者至少是您将要使用的表...
如果你有大量的表，你可以将它们分解为模式或其他一些分类方式，但我会说这个想法从来就不是每个表的数据模型......
答案 3 :(得分：1)
我将独立于数据库模式设计数据的概念/对象模型，然后创建最佳地将概念模型与数据库模式相关联的映射。它可能使用大多数（如果不是全部）表。如果您希望与表进行一对一映射，则可能需要考虑使用LINQ-to-SQL，因为它更易于使用。
答案 4 :(得分：1)
除上述答案外，请记住EF模型实际上处于概念层面。它不需要与数据库的结构有任何关系，当然也不需要代表整个数据库。
答案 5 :(得分：-1)
我认为如果您拥有大型数据库，那么您需要对数据库表进行分类。但是你必须为每个表创建一个类，这是ado.net实体框架的主要要求。
更新数据库时，可以使用更新数据模型。
首先设计数据库，然后创建ado.net实体模型。