Question

我通常喜欢自己创建数据库连接并使用`using {}'手动控制其生命周期。例如：

SqlConnection sqlConnection = new SqlConnection( connectionString );
using( sqlConnection ) {
    BusinessObject myBusinessObject = new BusinessObject( sqlConnection );
    // do stuff with the business object
    ...
}

通过这种方式可以看出我使用的资源需要适当清理。然而，这最终会导致很多重复的努力。我很想在业务对象中创建Sql连接并在其上实现IDisposable。我将在Dispose（）方法中关闭连接。

using( BusinessObject myBusinessObject = new BusinessObject() ) {
    // do stuff with myBusinessObject
    ...
}

我遇到的问题是，除非您看到业务对象正在使用中，否则可能并不那么明显。

你们会怎么做？

Answer 1

对于数据库，业务对象应该合理（或完全）愚蠢。您应该实现某种访问层对象（存储库或数据上下文），它知道如何将业务对象持久保存到数据库并保持连接逻辑，而不是将代码放在每个业务对象中。您的存储库或上下文将是一次性的，以便它可以自行清理。 @ Marc建议您遵循工作单元模式是一个很好的建议。

您可能希望查看LINQtoSQL，nHibernate，Subsonic等，以便使用它们，或者至少在如果您坚持编写自己的数据层时如何构建良好数据层的想法。根据个人经验，我可以告诉您，使用现有技术比编写和维护自己的技术要容易得多。

Answer 2

好吧，首先我要保持与存储库的连接。

其次，我不会在对象上留下连接 - 我只将它用于工作单元（即单个方法）。很可能（由于汇集）你会得到相同的物理连接。系统已经很长时间处理这些事情，所以你不必这样做。

更棘手的情况是事务，其中TransactionScope比传递db-transaction对象容易得多。

Answer 3

我不认为业务对象应该知道或关心它是否持久。一个持久的业务对象无法知道它何时属于更大的工作单元;这是服务层的责任。将连接保留在业务对象之外。服务层是获取连接的正确位置，通常来自连接池，设置事务边界，提交或回滚以及清理。

要在业务对象中封装数据库连接吗？

3 个答案: