Come migliorare l'applicazione a livello aziendale che consiste solo di metodi statici

Question

Come migliorare l'applicazione a livello aziendale che consiste solo di metodi statici

#1 da (3 voti)
#2 da (2 voti)
#3 da (0 voti)

3

Sono nuovo in un progetto di applicazione di livello enterprise e ho scoperto che il 99% di tutto ciò che ho visto nel codice sono metodi statici, proprietà statiche.

L'applicazione a portata di mano è un'app distribuita composta da una manciata di servizi WCF che comunicano attraverso un livello aziendale con un livello di accesso ai dati. Il componente di accesso ai dati è un singleton. Ci sono transazioni e code MSMQ e più parti che chiamano i servizi WCF per notificare al DB le modifiche, gli aggiornamenti effettuati in un sistema separato e così via.

La prima volta che eseguivo un piccolo progetto di test ho ottenuto un'eccezione relativa al thread utilizzando EntLib5 Logging, che mi diceva che un codice era stato chiamato da un blocco di codice non sincronizzato.

Sono curioso di sapere come si dovrebbe fare e migliorare un design quasi statico.

Are there advantages to the current approach?

What are the disadvantages?

Where would you start (besides starting over) and improve all this mess?

Grazie per le tue opinioni!

c# .net synchronization

posta John 01.09.2011 - 09:15

fonte

3 risposte

Leggi altre domande sui tag c# .net synchronization

In che modo un team di sviluppo di .NET deve progettare e fornire progetti greenfield? [chiuso] Design orientato agli oggetti dell'automobile [chiuso]

score 3 · Answer 1

Quando l'applicazione consiste solo di metodi statici, non è chiaramente orientata agli oggetti (tuttavia, ciò non significa che non si dovrebbero mai avere metodi statici). Inoltre, probabilmente non avremo test di unità minimi o nulli (dal momento che testare le cose statiche è quasi impossibile). L'unico vantaggio che posso pensare è che camminare nel grafico delle chiamate nell'applicazione è facile, perché è tutto statico, ma è quello che si ferma.

Sono sempre favorevole a un progetto sull'iniezione delle dipendenze, che consente il test delle unità e consente di collegare nuove funzionalità e problemi trasversali (come la registrazione e la sicurezza) più facilmente.

Ancora non esisterei per ricominciare tutto da capo, perché è troppo costoso (specialmente in un'applicazione enterprise) e sarebbe molto difficile stimare realisticamente il tempo necessario (cosa che farebbe impazzire i manager) e perderai i soldi dei tuoi boss.

No, invece, scopri la progettazione orientata agli oggetti, test delle unità , TDD , i principi SOLID , codice pulito e iniezione di dipendenza . Successivamente, prova a migliorare l'applicazione in piccoli blocchi al momento. Prova a scrivere un nuovo codice in base a questi principi e prima di modificare il vecchio codice (sia per correggere i bug che per modificare la funzionalità) prova a scrivere test automatici per quella parte del sistema. In questo modo puoi migliorare il codice con maggiore certezza.

Ci vuole un sacco di tempo per imparare, e lavorare in questo modo richiede molto tempo. Tuttavia, come hai detto tu stesso, sei in disordine, e non uscendo da questo pasticcio, significa che ad un certo punto nel tempo sarà impossibile cambiare qualcosa nel codice base. Il risultato sarà che in futuro potrai apportare modifiche con maggiore certezza e il sistema diventerà più manutenibile e più resistente ai cambiamenti.

Buona fortuna.

score 2 · Answer 2

Domanda difficile a cui rispondere, ma quanto segue dovrebbe portarti da qualche parte:

I metodi statici non sono intrinsecamente malvagi. Se incapsulano alcune funzionalità, allora è un modo completamente valido per fare qualcosa. Infatti ci sono interi paradigmi di programmazione come la programmazione funzionale che richiede solo lo stato locale.

Tuttavia, se ci sono dei campi di stato statici o delle proprietà che galleggiano, allora sarà problematico per quanto riguarda il threading, che sembra essere quello che stai vivendo in quanto esiste uno stato condiviso.

Vorrei:

Lose Enterprise Library: è uno spargimento in molti modi. Inserire log4net per la registrazione. Non è invadente come EL. Inoltre ostacola le prestazioni e presenta numerosi problemi di threading.
Trova qualsiasi variabile e proprietà di stato statico e cerca di renderli comprensibili. Questo probabilmente risolverà eventuali problemi di thread relativi allo stato condiviso. Se hai un metodo statico, ogni pezzo di stato toccato o restituito entra e esce molto attraverso i parametri o il valore restituito.
Trasforma tutte le classi in classi non statiche con metodi di istanza.
Prova e isola le dipendenze delle classi condivise in variabili di sola lettura locali (da iniettare in seguito).
Estrai le interfacce dalle classi e fornisci costruttori che accettano le dipendenze.
Utilizza un contenitore per costruire l'applicazione anziché le dipendenze.

Non sarà facile. Ripartire se il codebase è relativamente piccolo è probabilmente più semplice.

score 0 · Answer 3

Sembra un design molto scadente. Diamo un'occhiata da un punto di vista CLR puro. C'è poca differenza di prestazioni tra istanza e oggetto statico. Tuttavia, sarà presente un solo oggetto di tipo per una classe statica nell'heap gestito, pertanto non è possibile avere uno stato oggetto corretto, un singleton in effetti allo stack di chiamate. Steve ha ragione anche tu non puoi fare alcun IoC e sospetto che il threading diventerà anche più di un problema. Il design è molto accentuato e col passare del tempo aumenterà il costo di proprietà, un cattivo ROI. Il codice deve fare soldi. Se il refactoring è un'opzione, inizia dalla parte anteriore della tua app e inizia a introdurre le classi di istanza e tornare indietro. Questo potrebbe finire per essere silenzioso un grande refactoring composito ma hai poca o nessuna altra scelta che bin. Non ci sono vantaggi nell'avere un'applicazione statica. Ho avuto la stessa cosa in un'applicazione web una volta, abbiamo riscritto una grande parte di esso e alla fine l'ho abbreviato. BUONA FORTUNA.