将BLL类标记为静态或

Question

我已经有了一个工作良好的分层数据访问设计。但我不知道它是否是最合适的实现方式
我只是想知道BLL类或方法应该是静态的，或者它们应该是只有一个实例的concreate类
同时，我不需要序列化BLL类来在这样的SOA设计中使用它。但我不知道这个功能会带来什么
查看以下选项：

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

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

编辑：

选项1

public static class BllCustomer
{
    public static List<ModelCustomer> GetCustomers()
    {
    }
}
// usage
BllCustomer.GetCustomers();

选项2

public class BllCustomer
{
    public static List<ModelCustomer> GetCustomers()
    {
    }
}
// usage
BllCustomer.GetCustomers();

选项3

public class BllCustomer
{
    public List<ModelCustomer> GetCustomers()
    {
    }
}
// usage
BllCustomer bllCustomer = new BllCustomer();
bllCustomer.GetCustomers();

选项4

public class BllCustomer
{
    public List<ModelCustomer> GetCustomer()
    {
    }
}
// usage
public static BllCustomer s_BllCustomer = new BllCustomer();
// whenever needed
s_BllCustomer.GetCustomer();

Answer 1

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

静态类/方法或具体类/方法之间存在边际performance差异。对于主业务逻辑，我会回避静态类和方法，因为它们可能很难进行模拟/单元测试，而且不使用IoC容器。因此，考虑到这一点，我推荐你已经解释过的选项3。这里还有一些非常有用的答案。

Answer 2

为了提高性能和易用性，选项二最有意义。我现在使用选项2，没有遇到任何问题。其中大多数只包含一行调用DAL，然后包含另一行使用log4net进行日志记录。他们中的大多数人都没有太多的商业逻辑。

不过，我正在将其与ASP.NET一起使用。

Answer 3

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

我建议不要使类或方法成为静态的。原因是我发现DDD和依赖注入（IoC）这样的模式非常有价值。例如，您将如何测试一些使用此BLL的网站或应用程序代码？通常，你会想"模拟"你的BLL，这样它就会返回可预测的结果。使用静态类会很难做到这一点。