marking BLL classes as static or?

Question

I already have a layered data access design which works well. But i dont know if it is the most suitable implementation or not.
i simply want to know that BLL classes or methots should be static or they should be concreate classes which has only one instance?
In the mean time i dont need to serialize BLL classes to use it in such a SOA design. But i dont know what the feature will bring.
Look at the following options:

1. BLL classes and methots are static
2. BLL classes are not static but its methots are static
3. BLL classes are not static nor its methots. Application should create the BLL class everytime inorder to access its methots.
4. BLL classes are not static nor its methots. But there is only one instance of each BLL class. And application uses these static instances inorder to use BLL methots.

Which one is the most efficent mostly in performance and desing?

EDIT:

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

Serializing your Domain / BusinessLogicLayer classes sounds a bit unusual as your Domain layer typically holds you business rules and complex processing logic. Typically you will want to serialize your DataTransformation / POCO classes.

There will be marginal performance differences between static or concrete classes / methods. I would shy away from static classes and methods for you main business logic as they can be difficult to mock / unit test, plus don't work with IoC containers. So with this in mind I would recommend option 3 as you've explained it. There is also some extremely useful answers posted here.