DDD：服务和存储库实例将DI注入为单例

我最近对我的观点提出质疑，即单例只适用于日志记录和配置。依赖注入我现在没有看到你无法使用服务或存储库作为单身人士的原因。DDD：服务和存储库实例将DI注入为单例

由于DI通过接口注入单例实例，因此没有耦合。唯一合理的论点是您的服务可能具有共享状态，但如果您仔细考虑，服务应该是独立的单位，没有任何共享状态。是的，他们确实注入了存储库，但是只有一种方法可以创建存储库实例并将其传递给服务。由于存储库不应该有一个共享状态，我不明白为什么它也不能是一个单身。

因此，例如，一个简单的服务类应该是这样的：

public class GraphicService : IGraphicService 
{ 
    private IGraphicRepository _rep; 
    public GraphicService(IGraphicRepository rep) 
    { 
     _rep = rep; 
    } 

    public void CreateGraphic() 
    { 
     ... 
     _rep.SaveGraphic(graphic): 
    } 
}

没有一个国家在服务共享库之外也不会改变或有它自己的状态。

所以现在的问题是，如果您的服务和仓库没有任何国家，只有通过了，通过被实例他们为什么你会不会让他们为单身以同样的方式界面，配置或其他任何？

来源

2013-10-11 Sergey

是你的问题关于单身生活方式，或关于单身设计模式。你的问题并不清楚，但答案真的取决于它。 – Steven

单身人士的优点是什么？好像你在问未来的某个人会不小心加入给你所有问题的状态。 – JefClaes

只要你的版本库没有依赖关系，并且生命周期较短... –

如果您使用Singleton模式（即类的静态属性），那么您遇到了紧密耦合的问题。

如果您只需要一个类的单个实例，并且您正在使用DI容器来控制其生命周期，那么这不是问题，因为没有任何缺点。该应用程序不知道有一个单身人士，只有DI Container知道它。底线，一个类的单个实例是一个有效的编码要求，唯一的问题是你如何实现它。迪容器是最好的方法。 Singleton模式适用于快速肮脏的应用程序，在这些应用程序中，您不太关心可维护性和测试。

来源

2013-10-13 14:18:20 MikeSW

有些项目在依赖注入被填充之前使用单例进行依赖查找。例如iBATIS jpetstore，如果我没有弄错的话。它的方便，你可以gloablly访问诸如

public class GraphicService : IGraphicService 
{ 
    private IGraphicRepository _rep = GraphicRepository.getInstance(); 


    public void CreateGraphic() 
    { 
     ... 
     _rep.SaveGraphic(graphic): 
    } 
}

你的依赖，但这种损害的可测性（不容易更换与测试相关双打），并介绍隐含较强的依赖性（IGraphicService依赖于抽象和实现两者）。

Dependeny注射溶解这些。我不明白为什么在你的情况下不能使用单例，但是在使用DI时它不会增加太多价值。

来源

2013-10-12 01:09:16 Hippoom

DDD：服务和存储库实例将DI注入为单例

回答

相关问题