您的项目中是否可以有多个实体数据模型,还是应该始终只有一个?
我们有一个包含数百张表的大型数据库。 我们刚刚开始使用 Entity Framework 4。
我们应该为它构建一个巨大的数据模型,还是根据某些标准将其划分为许多数据模型?
We have a big database with hundreds of tables.
We are just beginning to use Entity Framework 4.
Should we build one huge Data Model for it or divide it into many Data Models based on some criteria?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我和我的同事在 Linq2Sql 时代就尝试过“一个真实的数据上下文”。我们发现它很快就变得难以维护。因此,我们现在选择了许多较小的“特定于任务”的上下文,我们发现它们的效果要好得多。
话虽如此,没有“正确”的方法。选择适合您的具体情况以及您将如何使用上下文的任何内容。
所以,恐怕这是另一个经典的这取决于答案。
PS - 我们的数据库中有大约 300 个表。其中 150 个左右出现在我们的模型中。
PPS - 我们现在正在转向代码优先,我个人比设计师更喜欢这一点。
My colleagues and I tried out the "One True Data Context" back in the Linq2Sql days. We found it quickly became awkward to maintain. So we've now opted for lots of smaller "task specific" contexts, which we are finding is working much better.
Having said that there is no "right" way. Go with whatever suits your particular situation and how you are going to use the context(s).
So, it's another classic it depends answer I'm afraid.
PS - Our database has about 300 tables in it. Of which 150 or so were in our model.
PPS - We're moving towards code first now, which I personally much prefer to the designer.