Question

可能重复：
Why not use an IoC container to resolve dependencies for entities/business objects?

我过去曾问very similar question。但是，我认为这不是一个自我重复：对我的原始问题的（好的）答案非常特定于这个领域问题，并且一般不讨论这个问题。

让我们来看一个新的例子：

我有一个Zone实体，带有相关的边界;
我有一个Store实体，其中包含location和zone属性;
ZoneRepository可以找到哪个Zone包含特定位置。

zone的{{1}}属性永远不应该直接设置，而是在分配此属性时从Store中扣除。因此，对我来说这听起来合乎逻辑：

location

这种方法有缺点吗？如果是这样，你能提出切合实际的选择吗？

Answer 1

区域和位置之间有什么关系？区域必须具有位置属性，对吗？否则您将无法按位置搜索。这可能是双向关系吗？我得到的是你为什么不能这样做？

class Store
{
    public function setLocation(Point $location)
    {
        $this->location = $location;
        $this->zone = $location->zone;
    }
}

或者，你冷却使用上面图层中的存储库，然后传递你需要的东西：

class Store
{
    public function setLocation(Point $location, Zone $zone)
    {
        $this->location = $location;
        $this->zone = $zone;
    }
}

通常，除非绝对必要，否则我不会注入存储库，在这种情况下它不会。即便如此，我也不会将其传递给方法，我会使用IOC容器传递它。

DDD：可以将存储库注入实体吗？

1 个答案: