Singleton Factory用于解析消息

时间:2012-01-23 04:34:37

标签: c# design-patterns

我们正在开发一个应用程序来处理各种XML消息并将它们加载到数据存储区中。我正在使用的一个开发人员使用反射创建了一个Singleton Factory来创建适当的消息子类的实例。我的问题是围绕工厂使用单例...(使用相同的东西构建SqlCommand对象需要传递给DB)。工厂肯定有意义,我模糊的部分是将Singleton与Factory结合使用。

我已经阅读了很多帖子,stackoverlow响应等,但我仍然不清楚为什么在这种情况下我们会使用该模式(Singleton与工厂...我会假设只使用一个工厂模式?)。

只是想更好地理解我收集到的内容,当您想要确保一个且只有一个界面时,您会想要使用Singleton吗?

1 个答案:

答案 0 :(得分:1)

单身人士无法确保单一界面;它们确保可以对其他对象进行全局访问的对象的单个实例。您可能希望使用单例的示例是您需要可从应用程序中的任何位置访问的计数器。换句话说,在整个应用程序生命周期内保持该单个对象的状态。

另一方面,工厂用于创建对象,您不一定知道返回的类的确切类型。例如,您可能有一个返回汽车对象的工厂,但返回的确切类可能是大众汽车,也可能是法拉利。

工厂被大量用于依赖注入(DI)。因此,在您给出的示例中,您可以使用工厂返回与DB接口的对象,但实际的类可以使用SQL语句与DB连接,也可以是使用对象关系映射(ORM)框架的另一个类。这将实际的数据库接口/实现与应用程序的其余部分分离,并允许更加灵活地更改数据库访问。工厂甚至可以返回可用于单元测试的DB访问模型。 DI可用于更改在运行时使用的方法。出于这些原因,我明确建议使用工厂。

工厂也可以归还单身人士。因此,在确定是否需要单例时要问的问题是,我是否需要在应用程序中维护将访问此对象的所有对象的状态。想要维护状态的一个示例是,您希望保持连接对数据库保持打开状态,以便在应用程序生命周期内访问此DB对象的任何对象。不建议您这样做,但它只是一个示例,说明为什么您可能希望在应用程序的生命周期内维护该对象的状态信息。