In the particular case of a data access layer I'd avoid static methods for one simple reason... coupling.
Static methods can't implement an interface, instance methods can. By using static methods one is essentially insisting against coding to an interface and instead coding to an implementation. Thus, everything which uses this data access layer is required to this this specific data access layer at all times.
No alternate implementations, no test stubs, no dependency inversion at all. The business logic has a dependency arrow pointing to an infrastructure concern (the data access layer), whereas that should be the other way around.
Additionally, it seems like this at least carries a greater risk of having problems with the disposal of resources. That might not be the case here, but it's really easy for it to become the case. What if a developer somewhere down the road has the bright idea to extract common lines of code into a class-level static method and property? Something like the Connection
or DBContext
object? That'll create some very interesting and very difficult-to-debug run-time errors.
On the other hand, if repositories were instances then they can simply implement IDisposable
and make sure any class-level objects are correctly disposed.
Continuing (I guess I had more objections to the design than I thought), this feels very counter-intuitive to me from an object-oriented sense. Perhaps this one is just personal preference, but this is turning what would otherwise be a "repository object" into a "dumping ground of DB helper methods."
In a system like this I would expect the number of random one-off methods to grow significantly over time as developers make quick solutions to meet requirements without thinking about the overall architecture. Instead of a consistent and well-managed series of objects, you could very likely end up with a bloated and difficult-to-follow codebase.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…