我已经要求使用单例模式实现的 DAL,但我认为很难汇集连接,使用事务..等等
我想知道利弊,也想知道连接连接的最佳方式,因为我正在开发的站点可能有超过 500 个并发用户。
数据库服务器是 Oracle 10g。
DAL 使用 Enterprise library 3.1
我已经要求使用单例模式实现的 DAL,但我认为很难汇集连接,使用事务..等等
我想知道利弊,也想知道连接连接的最佳方式,因为我正在开发的站点可能有超过 500 个并发用户。
数据库服务器是 Oracle 10g。
DAL 使用 Enterprise library 3.1
单例模式非常适合 DAL —— 我在自己的企业 Web 应用程序中使用它(数百个用户和 20 多个单例类中的 2,000 多个方法)。连接池确实由 ado.net 和 sql 服务器本身处理得最好。如果您想要拥有多种类型的后端服务器,那不是问题。即使使用单例模式,您也可能需要一个集中的数据访问类来处理实际直接调用数据库的细节(参数、文本/过程名称、凭据/连接字符串都传入)。
在我的情况下,单个方法上的每个方法与我的数据库中的存储过程 1:1 对应。这实质上为每个存储过程创建了一个 C#“前端”钩子,因此从语法上讲,它们几乎可以像本机 C# 代码一样被调用。它使对 DAL 的调用非常简单。由于有大量的 SP,我有多个单身人士。每个 SP 都有一个前缀,例如 Development_、Financial_、Organization_ 或其他。然后我有一个对应于每个的单例类,例如开发、财务或组织。所以 sp Organization_ViewData 在 C# 中将是一个名为 ViewData 的方法,位于名为 Organization 的单例类上。
当然,这只是一种实现方式,但我发现在过去六年中,它可以很好地与多个开发人员和大量代码一起工作。最重要的是一致性是关键。如果前端程序员正在查看您的一个单例代理上的方法的名称,那应该告诉他们确切地知道它进入数据库端的位置。这样,如果出现问题,或者如果有人不得不搜索代码以试图理解它,那么必须进行的跟踪就会减少。
连接池的最佳实践是不要自己实现它,而是让 ADO.NET 框架来处理它。
您可以将连接池选项设置为连接字符串中的参数。然后,使用该字符串打开的每个连接都将由框架实现和管理的连接池提供。当您关闭或处置 OracleConnection 时,底层连接不会被破坏,而是会返回到池中。
这在这里描述:http: //msdn.microsoft.com/en-us/library/ms254502.aspx
关于 Singletons 的一般使用:我用它们来包装数据访问层,它一直运行良好。
请注意,事务仅适用于特定连接,而不适用于整个数据库。这意味着您可以运行多个线程,并且每个线程可以通过独立的事务读取和写入数据库,前提是每个线程使用单独的 OracleConnection 实例。
我不了解 DAL,但单例模式是一种在保持良好封装的同时使数据全局化的好方法。
在 DAL 中为数据库连接工厂使用单例是很常见的。它使您可以更轻松地插入工厂的不同实现,而无需更改大量代码。很多人似乎不喜欢单例模式,但我认为它适用于这种类型的东西。
我认为无论是否使用单例都不会产生性能差异,因为您仍然可以同时在同一方法上运行多个线程。如果您注意没有将在所有线程中共享的内部字段,那么一切都会运行良好。
最后,管理连接池的类需要是线程安全的,您最终会制作一些可能影响性能的锁,但它们都是必需的。(它是在框架内部制作的,无论如何你都无法改变它的行为)
如果您决定不使用单例,请确保您的 DAL 实例是轻量级的,因为这可能会有所作为,但通常情况并非如此。
注意:谈到连接池,您必须注意的唯一重要的事情是遵循“迟开早关”的模式。这意味着,尽可能延迟打开连接,并在完成所有需要后尽快关闭它。
使用此魔术规则构建所有系统后,您可以使用连接字符串参数来更改一些池选项(初始大小,最大大小,...)
在 DAL 的情况下,我对使用单例有点不安。如果我想使用多个数据库后端怎么办。也许我想将 MsSQL 用于发票,但将 Active Directory 用于身份验证。或者也许我想使用 MySQL 来发布论坛帖子,但 PostgreSQL 用于地理集群(对我来说更现实,呵呵)。当我无法将模拟数据库连接传递给测试时,单例接口可能会使测试数据库层更具挑战性。