"Statico" a volte è una parola cattiva nel mondo C #, perché rende difficile creare Test di unità attorno alla classe in questione, a meno che la classe non stia facendo altro che l'elaborazione logica e non abbia database, I / O di file operazioni, o qualsiasi altro comportamento. Se stai trasmettendo dati o comandi da un livello all'altro, ti suggerisco di NON impostare la classe in modo statico.
Il tuo amico ha specificato PERCHÉ le tue classi di dati dovrebbero essere piccole? Sospetto che non sia a causa delle dimensioni della memoria, ma piuttosto perché è meglio rompere quelle classi di dati per essere il più piccolo e specifico di cui hai bisogno, e non di più. Quando entrate per la prima volta in OOP, c'è la tendenza a creare classi di "Dio" che hanno dozzine di metodi e campi. Questo sembra "giusto" all'inizio ("Oh guarda, ho tutto ciò di cui ho bisogno in una classe / spot, fantastico!") Ma rapidamente si impantana in un pasticcio non gestibile.
Un modello comune che mi piace usare è che il mio oggetto di trasferimento dati (o POCOS, hanno nomi diff) sia molto piccolo e molto stupido. Solo le strutture realmente (ma non la parola chiave "struct", è tutta una "palla di cera"), senza metodi o comportamenti di alcun tipo. Avere proprietà che eseguono il controllo nullo di base, la costruzione di stringhe e / o l'aggregazione su altri campi della stessa classe va bene, ma qualsiasi comportamento più grande va altrove. La classe che effettivamente funziona (database, file roba) è una classe separata con una serie di metodi che prendono questi oggetti di trasferimento dati come parametri, o li restituiscono come risultati. Questa classe "provider di accesso ai dati" non avrà molte proprietà e di solito implementa un'interfaccia (parola chiave: "interfaccia" in C #) che definisco che richiede quei metodi.
Il punto dell'interfaccia è che le mie app web o qualsiasi altra cosa può semplicemente chiamare quella classe attraverso l'interfaccia, e posso eseguire l'hot-swap in una classe diversa che soddisfi l'interfaccia che potrebbe semplicemente rilasciare dati fittizi, a scopo di test. Non puoi fare quel tipo di cose se la classe di accesso ai dati è statica.
Riepilogo: se vuoi veramente che la classe di accesso ai dati SOLO si comporti in un modo (in realtà attiva chiamate sql o file i / o e non sia "mockable") allora la classe di accesso ai dati può essere statico, ma lo raccomanderei contro. Ti troverai in un angolo più tardi, se parteciperai al test di unità / integrazione. ( Tuttavia, non sarebbe terribilmente difficile da refactoring a quel punto onestamente )