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