Ok, I'll chip in. There is nothing deeply wrong with static methods from a functionality point of view. If you are experiencing problems, it's not the static-ness of the method that is causing them.
Still, it's pretty bad OO design. They are basically global functions. You cannot use standard OO techniques such as inheritance with them. When you're writing
unit tests, it is impossible to hand your business code a stub or mock implementation of the data access layer. If you need to plug in a different data access layer - because you're prototyping something, because there's a requirements change but you want to retain the ability to quickly back out - you can't write a second implementation and plug that in.
The correct way is to define an Interface with the DAO methods, write a class implementing that interface, and hand an instance of that class as a collaborator to your business code.
I really have to plug those new-fangled Dependency Injection (aka Inversion of Control or IoC) containers here, such as the
Spring bean factory (warning: Spring is huge, don't try to use or even understand all of it at once, all the bits are independently useable). They make this highly object-oriented way of structuring your design really natural and enjoyable. Once the concept "clicks" with you, you'll wonder what masochism drove you to ever do without.
- Peter