So the situation is like, I have few classes, all of which have a standard CRUD methods but static. I want to create a base class which will be inherited so that it can force to implement this CRUD methods. But the problem is, the CRUD methods are static. So I'm unable to create virtual methods with static (for obvious reasons). Is there anyway I can implement this without compromising on static.

Also, the signature of these CRUD methods are similar.

E.g. ClassA will have CRUD methods with these type of Signatures

  1. public static List<ClassA> Get()
  2. public static ClassA Get(int ID)
  3. public static bool Insert(ClassA objA)
  4. public static bool Update(int ID)
  5. public static bool Delete(int ID)

ClassB will have CRUD signatures like

  1. public static List<ClassB> Get()
  2. public static ClassB Get(int ID)
  3. public static bool Insert(ClassB objB)
  4. public static bool Update(int ID)
  5. public static bool Delete(int ID)

So I want to create a base class with exact similar signature, so that inherited derived methods will implement their own version.

For E.g. BaseClass will have CRUD methods like

  1. public virtual static List<BaseClass> Get()
  2. public virtual static BaseClassGet(int ID)
  3. public virtual static bool Insert(BaseClass objBase)
  4. public virtual static bool Update(int ID)
  5. public virtual static bool Delete(int ID)

But the problem is I can't use virtual and static due to it's ovbious logic which will fail and have no meaning.

So is there any way out?

Also, I have few common variables (constants) which I want to declare in that base class so that I don't need to declare them on each derived class. That's why i can't go with interface also.

Anything that can be done with Abstract class?

  • 4
    Short answer: no, that is not possible. Inheritance mechanisms don't work with static methods.
    – Doc Brown
    Commented Nov 17, 2014 at 7:00
  • Why do you insist upon static? An instance method that doesn't use instance state, differs from a static method only in how it is called and it's parameters -- and of course the ABILITY to use state, but it looks like you are ruling that out by convention.
    – jmoreno
    Commented Nov 17, 2014 at 7:26
  • 1
    Only reason I'm insisting upon Static is because I don't want to create instance of class everytime just for calling the CRUD methods. Commented Nov 17, 2014 at 9:47
  • 1
    This might be a good candidate for IOC, let unity, ninject, etc do the instantiation for you.
    – JimS
    Commented Nov 18, 2014 at 13:00

4 Answers 4


Such methods shouldn't be static (what if you have to deal with two databases?) and they also shouldn't be on your entity classes.

Instead, you should have a separate type, that represents the storage for this entity. That type could be generic, so that code that's not entity-specific doesn't have to be repeated.

This way, inheritance works (storage for ClassA can inherit from some base storage) and you don't have to perform the nonsensical "I have to create a person to get a list of all persons".

This pattern is for example used by Entity Framework, there the storage type is called DbSet<T>.

  • Thanks a lot. Makes sense. But how do I go ahead for this StorageClass approach? I still have few grey areas regarding this. Do you mean to create a generic class like StorageClass<T> and use the CRUD Methods there? So whatever object I pass to to StorageClass<T> will it perform the CRUD accordingly. Commented Nov 19, 2014 at 3:00

You're going about this the wrong way. Any time you want to have a set of related methods like this and it looks like they should be static, consider the possibility that all this means is that you're trying to put them in the wrong place. In this case, you seem to be working towards the table data gateway pattern. Just move those methods into a separate class as virtual methods, have a single shared instance of each such class, and an abstract generic superclass to ensure the implementations are consistent.


Another way of handling this is that the base class takes a dependency of something like:

public abstract class MyBaseClass<T> : where T : object {
    protected IMyDataRepository _repository;

    public MyBaseClass(IMyDataRepository repository){
       _repository = repository;

    public abstract bool TryInsert(T item);
    // so you can implement explicit persistence on the derived classes


You can then use the repository to handle the state and persistence changes while uncoupling it statically from your class. You can achieve a degree of separation over inheriting directly from DbSet<T> if your program requires it.

See: https://www.martinfowler.com/eaaCatalog/repository.html


With static methods, you aren't going to get polymorphism or any sort of base class dispatch for these methods. So, I think you're looking for the 'wrong thing'. But don't let that get you down!

If you simply want to enforce that these methods are created on all classes deriving from a base, or interface, I can think of two easy ways off the top of my head.

First, in your unit test project, create a test that uses reflection across your assembly and fails if it finds any classes derived from your base that don't supply static implementations of your crud routines.

Second, create a T4 template that builds a junk class for each class derived from your base. In the junk class, place dummy calls to each crud method. When you compile, the compiler will choke on those missing static methods.

A non-technical solution would be to hit any developers who check in classes with missing static methods with a giant foam hammer during code-review.

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.