Marking BLL classes as static or?

Question

I already have a multi-level data access design that works well. But I do not know if this is the most suitable implementation or not.
I just want to know that the BLL or metaphoto classes should be static or should they be consistent classes that have only one instance?
At the same time, I do not need to serialize BLL classes to use it in such an SOA design. But I do not know what this function will bring.
Look at the following options:

• The BLL classes and metaphots are static.
• BLL classes are not static, but its metaphors are static.
• BLL classes are not static, nor are they its metaphors. An application must create a BLL class each time to access its snapshots.
• BLL classes are not static, nor are they its metaphors. But there is only one instance of each BLL class. And the application uses these static inorder instances to use BLL metadata.

Which one is most effective in performance and design?

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(); 

Option 3

 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 the Domain / BusinessLogicLayer classes sounds a little unusual, as your domain level usually contains your business rules and complex processing logic. Typically, you will need to serialize the DataTransformation / POCO classes.

Between static or specific classes / methods there will be marginal differences in performance . I would shy away from static classes and methods for your main business logic, as it can be difficult to mock them / unit test, and also not work with IoC containers. Therefore, with this in mind, I would recommend option 3, as you explained it. There are also some useful helpful answers posted here .

Answer 2

For performance and ease of use, option two makes sense. Now I am using option 2 and have not encountered any problems. Most of them just contain a line that calls DAL, and then another line that logs with log4net. Most of them do not have much business logic in them.

I use this with ASP.NET, however.

Answer 3

I personally created systems using many of these methods. In the end, I had to understand that I was too smart, because the easiest way was the most flexible. If you are tempted to do Static things because it seems like less work and therefore "more efficient", you are doing it for the wrong reasons.

I suggest NOT making a static class or methods. The reason is that I came to find patterns like DDD and Injection Dependency Injection (IoC) are very valuable. For example, how would you test any website or application code that consumes this BLL? Typically, you would like to “ridicule” your BLL so that it gives the expected results. It will be difficult for you to do this with static classes.