Some advice here,

I've run into a system where the DAL contents of hundreds of sql command calls are split up on a class per table. There are also a Business layer which get it's data from this DAL, recieving it further to other methods and layers in other places.

Nearly 100% of those Business Methods are pure forwarding of data. Few of them contain logic that affect the data (because the data are already sorted/evaluated or somewhat in the sql-commands/stored-procedures.

Now to the real question.
All of those methods in business layer are static.
This is easy because I can call them from everywhere without instantiation.

Is static methods really preferrable?
Why and how do you think?

I mean static methods need to be in heap and so far I really can't se the cosmetic profit because of it. I also feel the whole system is very hard to debug, especially now because the system has V E R Y high variety of response time, without many changes in load from users.

  • This doesn't sound like much of a "business layer" to me - are you sure you need one, or do you just have one for the sake of being n-tier?
    – Aaronaught
    Commented May 11, 2011 at 18:01
  • I am with aaronaught, dump the business layer if it isn't doing anything other than copying between object sets
    – Bill
    Commented May 11, 2011 at 18:59
  • Aaronaught, Bill. You probably right. The BL contains more logic, like you should expect of a business layer. 'Many of the methods are pointing to those "forwarding methods" (please help with a technical term), some of them to the DAL. I know the system was ordered with 3-tier as an important point, but this is most of the result. Commented May 11, 2011 at 19:17
  • It appears that nobody can feel positive to statics here? Commented May 11, 2011 at 19:17

2 Answers 2


No, Static Methods are very difficult to mock or handle via dependency injection, which you probably want to testing purposes at least.

  • That's a point. I'm creating a new DAL and BL logic for the system but feel responsible to check around for known advantages and drawbacks of the current techniques. Commented May 11, 2011 at 19:37
  • Do I need to describe the feeling for each step I can switch away the datasets and datarows.. Commented May 11, 2011 at 19:46

I mean static methods need to be in heap


Static methods may indicate a less than desirable design, but they could not in and of themselves the source of any significant performance issues. There is more overhead to an instance method.

Design usually suffers from use of static methods, and I use them rarely under very narrow circumstances - and when I do employ them, they are usually either a very general utility function (and often extension methods) or have a very limited scope of use (that is, any particular static method will have very few classes that use it, often only one and the static method is private).

  • Would statics be bad, if that's it? They have less overhead. How about design due to how statics being used? Ok, performance. The previous coder are probably better skilled then me but also not so innovative. Commented May 11, 2011 at 19:44
  • 1
    @Jonas: I made an edit to expand my answer rather than reply by comment. In short, I feel they restrict application architecture. It is a trade-off, though. Static methods and tight coupling is very straightforward, it's procedural code basically. Commented May 11, 2011 at 20:25
  • Thank's for the edit +1. I would say the same. Static methods are extensions or used for very slimmed circumstances, i.e. singletons. What I have here is a ocean of statics for general calls returning DataSets from a sql server. The whole system (we talk about 5 applications hosted this way) operates above this. So I'm confused :).. Commented May 11, 2011 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.