我想知道在标准3层应用程序中创建实例的替代方案和最佳实践是什么。
在用户界面中
- 我应该在表单加载时创建一个BLL对象，还是每次需要调用BLL方法时创建实例？
在BLL中：
- 我应该在BLL构造函数中传递一个新的DAL对象，还是应该在每个方法中创建一个dal？
DAL：
目前我的DAL传统上是使用oledb连接到AS400开发的，并利用ado.net进行所需的操作。执行命令完成后，每个方法都会打开和关闭连接。
- 这样可以吗？或者我应该跟随别的什么？
我的要求包括在我的UI中灵活的可能性，几乎可以为UI实现提供所有可能的案例（网页，winforms，e.t.c）。
答案 0 :(得分：2)
如果这是一个选项，可以使用依赖注入。这将使您的图层可测试且松散耦合...好的东西。如果您正在使用服务，那么这可能是您的业务逻辑的首选位置。
BLL然后可以实例化DLL，或者更好地注入它。我认为打开并立即关闭数据库连接是好的，但请尽量确保您使用域帐户或类似的东西，这样您就可以利用连接池。
由于您的要求包括UI的灵活性，您可能需要考虑MVP模式（Model-View-Presenter）。这将允许您使用选择WinForms，WebForms或两者作为您的前端。如果这是一个严格的要求，我强烈推荐这一点，因为它在这些情况下非常灵活。
这是对高级别问题的高级答案，您可以使用很多选项。这只是一个人的想法。如果您想了解更多细节，请与我们联系。
答案 1 :(得分：1)
创建您的对象，以便可以单独使用它们，这样它们就可以被嘲笑。能够在没有依赖“真实”数据库的情况下测试UI总是很好的。让您的BLL接受DAL的界面，这样您就可以在没有真正的数据库的情况下进行模拟和测试，等等。
你应该阅读像Ninject或AutoFac这样的依赖注入。它们将帮助您将参数传递给每个对象。
如果您最终使用仅适用于DAL的一个实现的BLL，那么如果它会影响另一个实体，则很难在一个层中进行更改。
你的应用程序的某些部分可能会向数据库提出一个巨大的请求，你觉得你可能不想为WebPage缓存这个响应，而不是在WebForms中。如果您只有一个实例来检索数据，那么在不涉及UI层的情况下很难设计一些缓存功能。如果你每次创建新实例，例如你可以有一个DAL，只用缓存函数包装原始实例。当您可以轻松告诉您的webapp使用缓存DAL时。
每次使用它时我都会创建新对象。