将BLL类标记为静态类还是？

Question

我已经有一个分层的数据访问设计，这是很好的工作。但我不知道这是否是最合适的实现。

我只想知道BLL类或methots应该是静态的，还是应该是只具有一个实例的concreate类？

同时，我不需要序列化BLL类就可以在这样的SOA设计中使用它。但我不知道这个功能会带来什么。

请看以下选项：

、

1. 、BLL类和methots是静态的，

、

1. 、BLL类不是静态的，但是它的方法是静态的，

、

1. 、BLL类不是静态的，也不是它的方法。应用程序每次都应该创建BLL类，以便访问它的方法。
2. BLL类既不是静态的，也不是它的方法。但是每个BLL类只有一个实例。应用程序使用这些静态实例来使用BLL .

。

在性能和设计方面，哪一个最有效？

编辑：

Option1

public static class BllCustomer
{
    public static List<ModelCustomer> GetCustomers()
    {

    }
}

// usage
BllCustomer.GetCustomers();

Option2

public class BllCustomer
{
    public static List<ModelCustomer> GetCustomers()
    {

    }
}

// usage
BllCustomer.GetCustomers();

Option3

public class BllCustomer
{
    public List<ModelCustomer> GetCustomers()
    {

    }
}

// usage
BllCustomer bllCustomer = new BllCustomer();
bllCustomer.GetCustomers();

Option4

public class BllCustomer
{
    public List<ModelCustomer> GetCustomer()
    {

    }
}

// usage
public static BllCustomer s_BllCustomer = new BllCustomer();
// whenever needed
s_BllCustomer.GetCustomer();

Answer 1

序列化域/ BusinessLogicLayer类听起来有点不寻常，因为域层通常保存业务规则和复杂的处理逻辑。通常，您希望序列化您的DataTransformation / POCO类。

静态类/方法与具体类/方法之间将有细微的performance差异。对于主要的业务逻辑，我会回避静态类和方法，因为它们很难模拟/单元测试，而且不能使用IoC容器。因此，考虑到这一点，我将推荐选项3，正如您已经解释过的。还有一些非常有用的答案张贴在here上。

Answer 2

对于性能和易用性，选项二最有意义。我现在使用的是选项2，没有遇到任何问题。它们中的大多数只包含一个调用DAL的行，然后包含另一个用log4net登录的行。他们中的大多数人并没有太多的业务逻辑。

然而，我在ASP.NET中使用这个。

Answer 3

我个人使用了很多这样的技术来构建系统。最后，我应该意识到我太聪明了，因为最简单的技术实际上是最灵活的。如果你想让事情变得静态，因为它感觉工作少了，因此“效率更高”，那么你这样做是出于错误的原因。

我建议不要使类或方法是静态的。原因是我发现DDD和依赖注入(IoC)这样的模式非常有价值。例如，您将如何测试使用此BLL的网站或应用程序代码？通常，您希望‘模仿’您的BLL，因此它返回可预测的结果。您将很难用静态类来完成这个任务。