在DAL中使用Singleton模式的利弊

Question

我已经要求使用单例模式实现DAL，但我认为很难汇集连接，使用事务......等等

我想了解优缺点，并且想知道汇集连接的最佳方法，因为我正在开发的网站可以有超过500个并发用户。

DB Server是Oracle 10g。

DAL使用Enterprise Library 3.1

Answer 1

单例模式非常适合DAL - 我在自己的企业Web应用程序中使用它（数百个用户和20个单独的类中的2,000多个方法）。连接池确实由ado.net和sql server本身处理得最好。如果您想拥有多种类型的后端服务器，那不是问题。即使使用单例模式，您可能还需要一个集中的数据访问类来处理实际直接调用数据库的细节（参数，文本/过程名称，凭据/连接字符串全部传入）。

在我的情况下，单个上的每个方法都与我的数据库中的存储过程1：1对应。这基本上为每个存储过程创建了一个C＃“前端”钩子，因此从语法上讲，它们几乎可以像本机C＃代码一样被调用。它使得对DAL的调用非常简单。由于有大量的SP，我有多个单身人士。每个SP都有一个前缀，如Development_，或Financial_，或Organization_或其他。然后我有一个与每个对应的单例类，如Development，Financial或Organization。因此，在C＃中的sp Organization_ViewData将是名为Organization的单例类上名为ViewData的方法。

当然，这只是一种方式，但我发现在过去六年中，与多个开发人员和大量代码一起工作得非常好。主要是一致性是关键。如果前端程序员在一个单独的代理程序上查看方法的名称，那么应该告诉它们到达数据库端的确切位置。这样一来，如果出现问题，或者某人不得不搜索代码以试图理解它，那么就必须进行较少的跟踪。

Answer 2

连接池的最佳实践是不自己实现它，而是让ADO.NET框架来处理它。

您可以将连接池选项设置为连接字符串中的参数。然后，将使用由该框架实现和管理的连接池提供使用该字符串打开的每个连接。当您关闭或处置OracleConnection时，底层连接不会被销毁，而是会返回到池中。

这里描述：      http://msdn.microsoft.com/en-us/library/ms254502.aspx

关于Singletons的一般用法：我用它们来包装数据访问层，它一直运作良好。

请注意，事务仅适用于特定连接，而不适用于整个数据库。这意味着您可以运行多个线程，并且每个线程可以通过独立事务读取和写入数据库，前提是每个线程使用单独的OracleConnection实例。

Answer 3

我不了解DAL，但单例模式是在保持良好封装的同时使数据全局化的好方法。

Answer 4

在DAL中使用单例作为数据库连接工厂非常常见。它可以让您更轻松地插入工厂的不同实现，而无需更改大量代码。很多人似乎不喜欢单身模式，但我认为它适用于这种类型的东西。

Answer 5

如果你使用单例，我不认为你会有性能差异，因为你仍然可以在同一个方法上同时运行多个线程。如果您没有在所有线程中共享内部字段，那么一切都会正常运行。

最后，管理连接池的类需要是线程安全的，并且最终会产生一些可能影响性能的锁，但它们都是必需的。 （它是在框架内部制作的，无论如何都无法改变它的行为）

如果你决定不使用单身，请确保你的DAL实例是轻量级的，因为这可能有所不同，但通常不是。

注意：谈到连接池，您必须注意的唯一重要事项是遵循“开放迟到，早关闭”模式。这意味着，尽可能地延迟打开连接，并在完成所有需要之后尽快关闭它。

使用此魔术规则构建所有系统后，您可以使用连接字符串参数来更改某些池选项（初始大小，最大大小......）

Answer 6

在DAL的情况下，我对使用单身人士感到有些不安。如果我想使用多个数据库后端怎么办？也许我想使用MsSQL作为发票，而使用Active Directory进行身份验证。或许我想将MySQL用于论坛帖子，但是PostgreSQL用于地理聚类（对我来说更真实，呵呵）。当我无法将模拟数据库连接传递给测试时，Singleton接口可能会使测试数据库层更具挑战性。