Implenting ActiveRecord con ereditarietà?

Non direi che questa è una cosa "cattiva" da fare. Ma ci sono alternative con i loro compromessi.

Supponendo che il modo in cui sono state utilizzate le classi originali fosse il pattern ActiveRecord, ecco alcune alternative.

1. Modificate il metodo Save() di ogni oggetto business per delegare l'operazione di salvataggio a una classe responsabile della gestione dello storage, che si tratti di XML o SQL. Invece di decorare ogni classe, puoi delegare il salvataggio a una singola interfaccia, ad esempio IDataStore . Ad esempio:

   public class SomeClass {
       IDataStore dataStore; // how this gets set can vary also
       public void Save() {
           dataStore.Save(this);
       }
   }
   

   Ora la modifica è nell'implementazione di IDataStore .

2. Continua a utilizzare i tuoi oggetti business nel livello aziendale, ma quando fai l'accesso ai dati, associa i tuoi oggetti business agli oggetti di accesso ai dati e usa Repository modello. Ad esempio:

   public class SomeBusinessProcess {
     public void DoSomeWork(SomeClass someClass) {
       // ... do some work on someClass ...
   
       // now save
       SomeClassDAO someClassDao = AutoMapper.Map<SomeClass, SomeClassDAO>(); // can use AutoMapper, for example
       repository.Save(someClassDao);
     }
   

Puoi davvero portarlo il più lontano possibile, in base a quali sono le tue esigenze.

In nessun modo questa non è una cosa "cattiva" da fare. Quello che hai fatto è simile allo schema del decoratore. link

In effetti ti suggerisco di leggere il pattern del decoratore poiché è uno strumento utile per il tuo arsenale di design.