Force Derived Class per implementare il metodo statico C #

Tali metodi non dovrebbero essere static (cosa succede se hai a che fare con due database?) e anche questi non dovrebbero essere nelle tue classi di entità.

Invece, dovresti avere un tipo separato, che rappresenta la memoria per questa entità. Quel tipo potrebbe essere generico, quindi il codice che non è specifico per l'entità non deve essere ripetuto.

In questo modo, l'ereditarietà funziona (l'archiviazione per ClassA può ereditare da qualche archivio di base) e non devi eseguire l'assurdo "Devo creare una persona per ottenere un elenco di tutte le persone".

Questo modello è ad esempio utilizzato da Entity Framework, lì il tipo di archiviazione è chiamato DbSet<T> .

Stai andando in questo modo nel modo sbagliato. Ogni volta che vuoi avere una serie di metodi correlati come questo e sembra che dovrebbero essere statici, considera la possibilità che tutto ciò significhi che stai cercando di metterli nel posto sbagliato. In questo caso, sembra che tu stia lavorando per il modello gateway dati tabella . Basta spostare quei metodi in una classe separata come metodi virtuali, avere una singola istanza condivisa di ciascuna di tali classi e una superclasse generica astratta per garantire che le implementazioni siano coerenti.

Con i metodi statici, non otterrai polimorfismo o alcun tipo di spedizione di classe base per questi metodi. Quindi, penso che tu stia cercando la "cosa sbagliata". Ma non lasciarti abbattere!

Se vuoi semplicemente far rispettare il fatto che questi metodi sono creati su tutte le classi derivanti da una base, o un'interfaccia, posso pensare a due semplici modi in cima alla mia testa.

Innanzitutto, nel progetto di test dell'unità, crea un test che utilizza la riflessione sull'assieme e non riesce se trova le classi derivate dalla tua base che non forniscono le implementazioni statiche delle tue routine crude.

In secondo luogo, crea un modello T4 che costruisca una classe di posta indesiderata per ogni classe derivata dalla tua base. Nella classe junk, inserisci chiamate fittizie su ciascun metodo crud. Quando si compila, il compilatore soffocherà su quei metodi statici mancanti.

Una soluzione non tecnica potrebbe colpire tutti gli sviluppatori che effettuano il check-in in classi con metodi statici mancanti con un martelletto gigante durante la revisione del codice.

Un altro modo di gestire questo è che la classe base prende una dipendenza da qualcosa del tipo:

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

}

È quindi possibile utilizzare il repository per gestire le modifiche di stato e persistenza durante il disaccoppiamento statico dalla classe. È possibile ottenere un grado di separazione rispetto all'eredità direttamente da DbSet<T> se il programma lo richiede.

Vedi: link