关于在干净体系结构中使用上下文的问题
我有一个干净的建筑项目，但我有一个问题。 我在域模型上进行了编辑和添加的新元素，我想可以。 但是删除呢？因为在这里，我需要有上下文来删除数据库中的元素。 我可以将上下文传递给域模型方法，还是会停止松散耦合体系结构？
这是应用程序层中处理方法的一部分：
entity.AddRestaurantTags(tagsChanges.Added);
entity.DeleteRestaurantTags(tagsChanges.Deleted, _context);
entity.EditRestaurantTags(tagsChanges.Edited);
await _context.SaveChangesAsync(cancellationToken);
或者我做错了，域模型应该贫血？ 我也可以在处理方法中将其做到，但是这些方法中有很多逻辑可以通过系统重复多次（也许不是在该特定示例中，但类似）
I have a clean architecture project, but I have an issue.
I make edits and addings new elements on domain model, and it's ok, I guess.
But what about deleting? Because here, I need to have context to remove elements from DB.
Can I pass context to domain model method or will it stop being loosely coupled architecture?
This is part of handle method in Application layer:
entity.AddRestaurantTags(tagsChanges.Added);
entity.DeleteRestaurantTags(tagsChanges.Deleted, _context);
entity.EditRestaurantTags(tagsChanges.Edited);
await _context.SaveChangesAsync(cancellationToken);
Or I'm doing it wrong, and domain model should be anemic?
I can make it also in handle method, but there is much logic in these methods that repeats many times through system (maybe not in that particular example, but similar)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不应该将DBContext传递到您的实体中。这意味着您的核心域项目必须对EF有一个引用，因为这会增加对基础架构/实现细节的依赖性。
如果您只是删除内容，则可以简单地从实体的子收藏中删除事物，然后在保存实体时，将删除孩子。我认为您已经明白了，我只是指出它的完整性。
但是，如果您需要在删除之前进行一些逻辑，该逻辑需要其他数据呢？好吧，您有选择。
放弃DDD，然后将所有逻辑放入服务中。使您的实体贫血并赋予其公共可变特性。在服务中完成您需要的一切。我不推荐这个
将您的方法需要的数据传递到其中。无论您需要dbContext的数据，只需在删除方法中以参数索取即可。您正在删除餐厅上的标签，因此也许您正在检查它是否是最后一个标签，以便您可以删除相应的标签，或者可以防止删除。因此，要求CurrentTagCount作为参数。
使用域事件。如果您不需要dbcontext可以防止操作，而是要进行一些后续操作（例如，在餐厅删除标签后，如果标签在任何地方都没有使用，请删除其相应的记录），请提高事件。然后，在事件处理程序中，您可以执行后续行为。请参阅我的清洁架构模板对于为此起作用的示例域事件实现。
通过irepository抽象。
通过我的服务抽象。
通过弹药或动作。
我查看了许多不同的方法来解决此问题（包括上面列出的一些问题），其中显示了如何在实体中实现唯一检查：
https://github.com/ardalis/ddddddddddduplicates
检查一下，让我知道其中一种选项是否适合您的情况。如果您需要更具体的指导，显然将有助于查看您的删除方法的作用以及为什么需要DBContext。
You shouldn't pass the dbcontext into your entity. That would mean that your Core Domain project must have a reference to EF, which you don't want as that would add a dependency on an infrastructure/implementation detail.
If you're just deleting stuff, you can simply remove the things from the child collection of the entity and then when you save the entity, the children will removed will be deleted. I think you already get this, I'm just pointing it out for completeness.
But what if you need to do some logic before the deletion, which requires additional data? Well, you have options.
Give up on DDD and just put all the logic in a service. Make your entity anemic and give it public mutable properties. Do everything you need in a service. I don't recommend this but it's what many developers end up doing if they can't come up with a better pattern.
Pass the data your method needs into it. Whatever data you need the dbContext to go get, just ask for it in your delete method as a parameter. You're deleting a tag on a restaurant, so maybe you're checking if it's the last tag so you can delete the corresponding tag or so you can prevent the delete. So, ask for the currentTagCount as an argument.
Use a domain event. If you don't need the dbContext to possibly prevent the operation, but instead to do some follow-up (e.g. after the tag is deleted on the restaurant, if the tag isn't used anywhere, delete its corresponding record), just raise an event. Then in an event handler you can do the follow-up behavior. See my Clean Architecture template for an example domain events implementation that would work for this.
Pass in an IRepository abstraction.
Pass in an IWhatever service abstraction.
Pass in a Func or Action.
I look at many different ways to approach this problem (including some of the ones listed above) in this GitHub repo showing how to implement a unique check in an entity:
https://github.com/ardalis/DDD-NoDuplicates
Check it out and let me know if one of those options works for your scenario. If you need more specific guidance it would obviously help to see what your delete method is doing and why it needs a dbContext.