Impedire ad altri sviluppatori di utilizzare metodi di base all'interno di una classe

Ho una classe che utilizza le entità del filesystem per manipolare i dati. Abbiamo diversi metodi specificamente progettati per (tentare di) affrontare alcuni dei problemi che affrontiamo con questo approccio (blocco dei file, file inesistenti, ecc.). Idealmente mi piacerebbe essere in grado di emettere un avviso se un altro sviluppatore tenta di accedere al filesystem direttamente tramite System.IO piuttosto che utilizzare i metodi helper.Impedire ad altri sviluppatori di utilizzare metodi di base all'interno di una classe

È possibile? Il comportamento che sto cercando è quello di contrassegnare efficacemente metodi come File.ReadAllText() come se fossero obsoleti, ma solo all'interno di questo progetto (NON a livello di soluzione).

Ho fatto qualche ricerca, e sembra che la mia unica opzione sia "dì loro di assicurarti che usino i tuoi metodi". Spero che qualcuno possa darmi una risposta diversa e più utile. :)

--EDIT-- I suggerimenti di una regola StyleCop o FxCop personalizzata sono buoni, ma sfortunatamente poco pratici in questo scenario (non tutti gli sviluppatori del reparto utilizzano questi strumenti eccellenti) e i metodi legittimi che eseguono il comando. accesso file do utilizzare System.IO. Aggiungere gli attributi "ignora" ai metodi legit è anche un'idea pericolosa. Se qualcuno vede come ho "rotto" la mia regola, probabilmente copierà l'attributo nel proprio metodo.

fonte

2010-02-04 ZombieSheep

Fake it. Per poter usare System.IO, devi * fare riferimento * a prima, in un 'using' o direttamente. Quindi tutto ciò che devi fare durante una revisione del codice è un "Trova in tutti i file" per 'System.IO'. –

Come ripensamento, potresti probabilmente avvelenare lo spazio dei nomi introducendo intenzionalmente dei conflitti, ma questo sembra essere molto più difficile di quello che vale. –

Un'idea interessante, ma i metodi "autorizzati" devono anche utilizzare System.IO. Trovare usi illegittimi all'interno della base di codice potrebbe essere complicato. – ZombieSheep

Utilizzare uno strumento di analisi statico (come StyleCop o FxCop) con uno rule che cattura "Non utilizzare System.IO direttamente". Quindi integralo come parte del tuo processo di compilazione automatica e vomita se qualcuno tenta di utilizzare direttamente System.IO. A nessuno piace rompere la build.

fonte

2010-02-04 15:04:20 jason

Mi piace rompere la build. –

È grandioso. Spero ti piaccia anche aggiustarlo. –

Mi piace questa idea. Sfortunatamente noi (come organizzazione) non imponiamo ancora l'esecuzione di StyleCop o FxCop su build (dovremmo, e ho insistito per un po ', ma il cambiamento è lento) Suppongo di poter modificare l'idea e aggiungerla a il mio set di regole, ma poi divento un singolo punto di controllo qualità per questo modulo. – ZombieSheep

È possibile scrivere custom analysis rule per FxCop/Visual Studio Code Analysis ed eseguirli come parte della build automatizzata.

fonte

2010-02-04 15:06:42

Sì, o renderlo un requisito per il check-in, in TFS. –

Hmm. Non l'ho provato personalmente, ma per quanto riguarda il forzare le persone a utilizzare le classi di gestione dei file personalizzate, utilizzando un alias dello spazio dei nomi che "nasconde" il vero System.IO. Se ricordo bene, questi sono applicati a livello di progetto.

fonte

2010-02-04 15:22:51 ChrisBD

Sembra un po 'l'idea di "avvelenamento del namespace". Il problema è che probabilmente c'è un modo per specificare il vero System.IO anche quando un falso blocca il percorso più diretto, così questo impedisce * accidentalmente * di bypassare il livello I/O del file personalizzato senza fermare qualcuno che lo vuole davvero. Questo include coloro che hanno pensato che il problema fosse un bug, non una funzionalità intenzionale (o lo rivendicherebbe). –

Ah sì non avevo notato il tuo commento. E 'questo che intendevi? Non vedo come fermerebbe le persone che digitano intenzionalmente tutto a mano nel loro codice per accedere allo spazio dei nomi System.IO senza di esso. – ChrisBD

Controlla il mio prossimo commento, in cui suggerisco di rimuovere semplicemente l'assembly con System.IO dall'elenco dei riferimenti. –

Non

sicuro se uno di questi suggerimenti sono validi come non ho mai fatto, ma alcuni spunti di riflessione:

Non è questo ciò che "Modelli Enterprise" sono progettati per? Non ti consentono di creare un file di criteri che limiti i riferimenti di progetto consentiti?

In alternativa, mentre non è infallibile, è possibile aggiungere un evento pre-build al progetto che genera un avviso se si fa riferimento a System.IO?

fonte

2010-02-04 15:50:21

È possibile aggiungere alcune funzionalità personalizzate a un hook di commit del controllo sorgente? Non troverà le violazioni esistenti (se ce ne sono) a meno che quei file non vengano modificati, ma dovrebbero rilevare nuovi usi?

Qualsiasi buono?

fonte

2010-02-04 16:10:04

Impedire ad altri sviluppatori di utilizzare metodi di base all'interno di una classe

risposta

Problemi correlati