EF核心中使用的单独域模型和实体？
我不确定是否应该让EF使用我的域模型。
目前，我有三种类型的模型：
- Wide）
- （仅用于控制器）
- 基础结构。
（ System
- API.Models
- core.models 在基于请求
- 保存
的实体上，使用域实体时，此功能很棒，因为EF开始跟踪更改，并且只能持续使用已更改的内容。
如果我从DB检索时将其映射到域模型，以便我的服务仅在域模型上使用，那么我的更改当然不会跟踪：
- 从DB中获取实体，并将其映射到域模型
- 上的域模型更改属性基于请求
- 映射回到实体
- DO复杂的图形diff（由于没有跟踪更改以来，手动对已更改的内容设置状态）
- 保存更改，更改
实体不包含数据注释，也没有任何内容，我使用fluent api。我认为分离域模型和实体毫无意义。我正在研究吉米·博加德（Jimmy Bogard），史蒂夫·阿达利斯（Steve'Ardalis）史密斯（Jason Taylor）的示例，他们都将自己的域模型用作EF实体。他们是为了使代码简单地出于演示目的而这样做，还是对分离模型和实体不利？
Im unsure on wether I should let EF use my domain models or not.
Right now I have three types of models:
- Core.Models (System wide)
- API.Models (Used only in controllers)
- Infrastructure.Entities (Only used for persistence)
Every method in my service classes look like this:
- Get entity from DB
- Change properties on entity based on request
- Save changes
This works great when using the domain entities, as EF starts tracking the changes and can persist only what's been changed.
If I instead map to domain models when retrieving from the DB, so that my services only work on domain models, my changes aren't tracked of course:
- Get entity from DB, as untracked, and map to domain model
- Change properties on domain model based on request
- Map back to entity
- Do complex graph diff (set state manually on what has been changed since changes aren't tracked)
- Save changes
The entities contain no data annotations or nothing, I'm using the Fluent API. I see no point in separating domain models and entities. I'm looking at examples from Jimmy Bogard, Steve 'Ardalis' Smith, Jason Taylor, and they are all using their domain models as their EF entities. Are they doing that to keep the code simple for demo purposes or is not beneficial to separate models and entities?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论