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:

BLL classes and methots are static
BLL classes are not static but its methots are static
BLL classes are not static nor its methots. Application should create the BLL class everytime inorder to access its methots.
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();

Why should people insist not giving an opinion to this issue, i simply can not understand. possibly, they can not see this topic in many other questions. yes i am talking to myself. — Fer, Jan 19 '12 at 13:20

score 1 · Answer 1 · edited May 23 '17 at 12:22

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.

Upon reading the question the first thing I thought about was the issues with mocking. Upvoted for that and the info about IoC containers — Mike, Jan 24 '12 at 22:16

score 0 · Answer 2 · answered Jan 24 '12 at 16:33

0

For performance and ease of use, option two makes the most sense. I'm using option 2 now and have not run into any issues. Most of them just contain a line that calls to the DAL and then another line that logs with log4net. Most of them don't have a lot of business logic in them.

I'm using this with ASP.NET, however.

answered Jan 24 '12 at 16:33

O.O

11,077
18
94
182

you said you would choose option 2. what do you think about the difference between option 1 and option 2? they are both easy to use and static. why not to choose option 1 then? – Fer Jan 26 '12 at 11:59
I don't use option 1 because it is too rigid. With a static class, all your members must be static. It is more typical to have a non-static class with static members than a static class. You can still create an instance with option 2, but you are stuck with a static class with option 1. Go with what is easiest. Also, option 1/2 are not ideal for unit testing, but if you don't have much in those methods, then unit testing is not necessary anyways. Most of my logic is in stored procedures, depends. – O.O Jan 26 '12 at 14:11

score 0 · Answer 3 · answered Jan 25 '12 at 04:45

I've personally built systems using a lot of these techniques. In the end I should have realized I was being too clever because the simplest technique was actually the most flexible. If you're tempted to make things Static because it feels like less work and therefore 'more efficient' then you're doing it for the wrong reasons.

I suggest NOT making the class or the methods static. The reason being that I've come to find patterns such as DDD along with Dependency Injection (IoC) very valuable. For example, how would you test some website or application code which consumes this BLL? Typically you would want to 'mock' your BLL so it returned predictable results. You'll have a hard time doing this with Static classes.

marking BLL classes as static or?

3 Answers3