C# 我的Ui将在每次使用中创建业务对象？还是不？

尝试在我的新应用程序套件中构建一个基本的三层体系结构。我第一次想开始应用最佳设计实践（比如IoC/DI e.t.c）

我的UI层必须创建一个BLL对象才能工作

假设我的UI需要调用BLL 10次。我必须创建我的BLL对象10次还是在表单加载时创建一次

我的UI层必须创建一个BLL对象才能工作

首选做法是在创建或稍后通过属性将业务层对象的接口注入到GUI表单中。在这种情况下，表单对业务层对象一无所知，不需要实例化它们，只做它应该做的事情——GUI交互

就我个人而言，我更喜欢构造函数注入：

public class MyForm
{
    private IDocumentStorage documentStorage;
    private IJobsRegistrator jobsRegistrator;

    public MyForm(IDocumentStorage documentStorage, IJobsRegistrator jobsRegistrator)
    {
        this.documentStorage = documentStorage;
        this.jobsRegistrator = jobsRegistrator;
    }
}

---

其中，

IDocumentStorage

和

ijobsregistor

是您的业务层接口。如果有一些限制（例如，您只能使用无参数构造函数），您可以使用属性设置器。。。如果你希望得到一个直截了当的答案，你会失望的。答案是——视情况而定

如果你的对象是一个无状态的轻量级对象——如果它能让你的生活更轻松的话，那么每次都可以创建它

另一方面，如果您的对象必须维护状态，或者需要大量资源来创建，则必须将其创建为单例，并承担创建/管理单例所需的所有开销

---

DI容器支持这两种方案，但这取决于您为您的方案选择正确的方案

通过每次调用重新创建业务对象是正常的。 这有助于维护无状态应用程序，如果您正在创建基于HTTP的网站，这就是您想要的

---

如果由于某些真正的重量级对象而出现问题，则可以采取一些措施，例如创建对象缓存/池，或在会话对象中保存内容。如果对象是服务类型的类，也就是说，接受一些输入并提供一些输出（例如存储库类型的对象），则您希望UI层依赖于它的抽象版本，例如：

public class UILayerComponent
{
    private readonly IBLLObject _bllobject;

    public UILayerComponent(IBLLObject obj)
    {
        _bllobject = obj;
    }

}

但是UI层不应该知道这个对象的实例化、生命周期管理，甚至是具体实现。这应该是IoC容器要处理的工作

---

但是，如果对象是状态驱动的（例如，由一个用户操作创建，并由另一个用户操作更新或删除），那么您应该在有意义的时候创建并处理它。

严格地说，是简单的3层

第1层-数据库 这里没有逻辑，只是通过RDBMS机制进行数据检索和存储

第2层-业务逻辑/数据访问 数据访问对象（向第1层传递/获取数据，业务对象应在此处创建）和业务数据（域）对象应在此处创建/填充/保存

第2层用户界面

---

只向用户提供数据（在从Tier 2获取的业务对象中）以供用户创建/操作

，因此如果我理解正确，我将在使用时多次将BLL对象注入我的UI。@e4rthdog否，你在表单创建时注入它们一次并保留引用。如果我的BLL和DAL被windows表单和web应用大量使用，singleton不是一个坏选择吗？这取决于你如何定义“singleton”-大多数IoC容器支持singleton类型生存期管理的概念，但这并不意味着对象本身是作为单个对象实现的。因此，例如，如果我有一个简单的条形码应用程序，希望检查是否存在大量的条形码，每次用户按下按钮时，我都应该创建一个BLL对象（通过将DAL对象注入其构造函数）并调用BLL方法进行批量检查，该方法将应用我想要的逻辑并与DAL交互。对吗？@e4rthdog我的第一个想法是这样的事情可以在静态类/方法中处理。在这种情况下，您不需要实例化任何内容。有什么原因需要一个实际的对象吗？我可能需要有多个dal，这取决于我的后端数据库，通常它会随着时间的推移而变得复杂和需要