我正在努力设计一个设计,并试图找出实现它的最佳方法。
我们有很多表,在当前的 LinqToSql 实现中,我们的 DBML 大小有很多兆,非常笨重。如果可以的话,我想避免重现这种情况。我们根据每个用户决定连接字符串,因此为不同的表组创建单独的 dbml 非常困难。
我决定使用实体框架,虽然我们不需要 Code First 元素,但我喜欢无需生成的轻量级代码,并且我们不需要可视化映射,因此我正在考虑生成代码文件对于所有表,然后将它们作为 DbSet 添加到 DataContext 中。
这让我思考这里的最佳实践,我想问这个问题;
为要使用的每组表创建一个 DataContext 是否明智?即我将有一个模块,它将负责从 5 个表收集数据,它不需要数据库中的每个表,只需要 5 个。我是否创建一个包含这 5 个表的 DbContext。如果我将来需要更多,我可以添加它们,但它是轻量级的。
I'm wrestling with a design and trying to figure out the best way of approaching it.
We have many tables, and in a current LinqToSql implementation, our DBML is many megs in size, very unwieldy. I want to avoid recreating this situation if I can. We decide our connection string on a per user basis, so it got very difficult to make separate dbmls for different groups of tables.
I'm set on using Entity Framework, and although we don't need the Code First elements, I'm liking the lightweight code without all the generation and we don't need the visual mapping so I was thinking of generating the code files for all the tables and then adding them into a DataContext as DbSets.
This got me thinking about best practice here, and I wanted to ask the question;
Is it wise to create a DataContext for every group of tables you want to use. I.e. I'm going to have a module, it will be responsible for gathering data from 5 tables, it doesn't need every single table in the database, just 5. Do I create a DbContext that includes these 5 tables. If I need more in the future I can add them in, but it's lightweight.
发布评论
评论(3)
虽然每个表分组可能有单独的上下文,但如果您的模型那么大,或者您的域不同,您可能需要考虑添加一个抽象层。我的意思是拥有一个包含整个模型的上下文,然后按照 存储库模式。 这是一篇关于使用 EF 完成此任务的不错的文章。
通过这样做,您基本上可以实现两个目标:抽象出数据层,从而消除实施问题;并且,允许您的开发人员仅使用他们需要的实体,可能按 聚合根。
但我想澄清一件事。我不一定建议您采用特定的端到端架构(即 DDD)。我在这里试图做的是建议一些模式,这些模式将为您提供灵活性,允许您犯错误(优雅地失败),同时仍然使您的项目取得进展。
While you may have a separate context for each grouping of tables, if your model is that large, or your domains that disparate, you may want to look into adding a layer of abstraction. By this, I mean having a single context that encompasses your whole model, then adding something along the lines of the repository pattern. This is a decent write-up on accomplishing this with EF.
By doing this, would you be essentially accomplishing two goals: abstracting out your data tier, thus freeing up implementation concerns; and, allowing your developers to work with just the entities they need, possibly grouped by aggregate root.
One thing I would like to make clear though. I am not necessarily suggesting that you go with a specific end-to-end architecture (i.e. DDD). What I am trying to do here is suggest a few patterns that will give you the flexibility to allow you to make mistakes (fail gracefully) while still making progress with your project.
你当然可以做到这一点。您只需将表添加到 edmx 模型中,就像在 Linq2SQL 中一样,因此只需添加所需的 5 个表,您就可以节省对其他未跟踪表进行实体跟踪的任何开销。实体框架很好地添加了 Linq2SQL 所没有的 2 向导航属性。我建议使用 EF 而不是 Linq2SQL。
You can certainly do this. You just add tables to the edmx model just as in Linq2SQL so by just adding the 5 tables you need you'll save on having any overhead for entity tracking for the other untracked tables. Entity Framework nicely adds 2-way Navigation Properties which Linq2SQL doesn't have too. I'd recommend using EF instead of Linq2SQL.
大型 DBML 模型本身并没有什么坏处,在 EF 中对性能的影响应该可以忽略不计。
另一方面,我认为降低复杂性也适用于实体框架 - 如果您的代码只需要数据库中的 5 个表,那么请务必创建一个单独的上下文,其中仅包含这 5 个表的实体。通过将完全独立的表分解到单独的上下文中,您可以清楚地表达这种分离 - 这些表与数据库中的其他表没有依赖关系,并且代码与不相关实体之间没有依赖关系 - 如果是这种情况,我认为(可能还有其他意见)这就是要走的路。
但是请记住,如果您需要在另一个上下文中使用其中一些表,您也必须将相应的实体放入该上下文中 - 很难理解相同的表存在于多个上下文中,甚至具有交叉依赖关系上下文之间。应该避免这种情况,因为它会增加复杂性。
There is nothing inherently bad about a large DBML model, the performance impact should be negligible in EF.
On the other hand in my opinion reducing complexity also applies to Entity Framework - if your code only needs 5 tables from the database by all means create a separate context that only has the entities for those 5 tables. By factoring out completely independent tables into separate contexts you are expressing this separation in clear way - there are no dependencies from these tables to other tables in your database, and no dependencies from the code to unrelated entities - if that is the case I think (and there might be other opinions) this is the way to go.
However keep in mind that if you need some of those tables in another context you would have to put the corresponding entities into that context as well - it can get hard to understand that the same tables are present in multiple context or even have cross-dependencies between contexts. That should be avoided since it adds complexity.