2

最近,由于无知和时间紧迫,我将多个项目中的域模型(POCO 实体类)合并到一个“DataModel”项目中,因为我不想在所有项目中复制专用的 DbContext。让我印象深刻的是,可以完成一些通用的事情,比如 DbContext 扩展,可以从各种客户端项目中添加 DbSet 实例。

我读过提到这些事情,通常与作者在同一个圈子里争辩 - 我完全同意 - 存储库功能完全由 DbSet 类实现。

任何人都可以为构建一个可以存在于一个项目中的通用 DbContext 提供任何建议,其中其他项目都可以将其域模型(域实体集)注册到共享 DbContext 中,在那里它们都被分配了他们拥有的 DbSet 作为他们的存储库?

4

1 回答 1

0

构建一个可以存在于一个项目中的通用 DbContext,其他项目都可以注册其域模型(域实体集)

有趣的想法,但我不确定你会从中获得什么。

一方面,您永远无法简单地输入db.Customer(或类似的)。应该一直是genericdb.Set<Customer>()根本不知道genericdb不知道Customer。(它可能尚未注册)。

那么,这个注册应该如何进行呢?有两种方法可以让上下文将类映射到数据库模型:

  1. 在 - 派生类中创建DbSet属性DbContext并依赖于代码优先的默认约定,涉及表名和列名、复数等。
  2. 提供映射配置。

第一个选项违背了通用上下文类的目的,因此您必须通过为域中的每个EntityTypeConfiguration<T>类提供s来注册域类,对于通常可以不用的类也是如此。(顺便说一句,这应该在上下文的构造函数中完成。)

进一步的暗示是,在某个地方,您需要一个组件/服务,该组件/服务知道哪些类组属于一起,并且能够提供连贯的配置列表。因此,您必须创建自己的组织者,而不是将专门的上下文作为开箱即用的组织原则。

但回到起点。您不能创建一个包含 DbContext 工厂的 DAL,该工厂提供以前为您的项目存在的上下文吗?您不必以这种方式复制专用的 DbContext 类。

于 2013-04-06T21:35:13.430 回答