In layered architecture does it matter where static methods go? Or is it the architect deciding this? For example can the DAL be static to cache records and perform smart data retrieval at the application level? How about the service layer; can it be non-static?

I ask this because I have seen examples from good architects that employed static methods in their service layer -and I usually try to avoid them unless it's a matter of performance and efficiency (e.g. for record caching).

  • 1
    What does the static-ness or non-static-ness of a method have to do with architecture? To me that sounds like asking what the number of coins in your pocket has to do with your employer's profitability. Architecture is supposed to be a very high-level thing that is rarely directly influenced by low-level details like exact function signatures.
    – Ixrec
    Commented Mar 27, 2016 at 1:29
  • In my opinion it matters if you want to build a maintainable and expandable solution. Think about it from the average programmers' perspective; what and how should they build upon your application without causing a mess somewhere else? How can they maintain your code with ease? How can your application stay efficient? I know I wouldn't want to tamper with a static method in the BL that's referenced by 20 classes -even with perfect documentation (rarity) in front of me! So is it possible to use static methods in the BL and still be fine? The architecture should address these concerns.
    – Mossi
    Commented Mar 27, 2016 at 3:14
  • What examples do you see static is serving safely in DAL (maybe other than parameters or connection strings)? Consider thread safety, see: stackoverflow.com/questions/6941181/…
    – NoChance
    Commented Mar 27, 2016 at 4:53
  • I see DAL as a brainless layer that facilitates CRUD operations. In my view to make the data retrieval part more efficient I can use static variables to cache data that's already retrieved.
    – Mossi
    Commented Mar 27, 2016 at 5:12

1 Answer 1


In my opinion, static items are hard to control, because they can't easily be bound to a context, be abstracted or overridden. Sometimes, when really just one instance is needed, a singleton can be a solution.

Common object-relational mappers, like NHibernate, create local contexts in which data is cached (depending on implementation, these may be bound to semi-static thread or web session contexts). But actual implementation is usually not static.

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.