Il modo migliore per gestire la confusione tra codice aziendale e presentazione?

Question

Considerando una situazione ipotetica in cui una vecchia libreria di presentazioni legacy è stata mantenuta nel corso degli anni e al suo interno è stata gradualmente codificata sempre più logica aziendale attraverso un processo di correzioni frettolose e la mancanza di un'adeguata supervisione dell'architettura.In alternativa, considera una classe aziendale o uno spazio dei nomi che non è separato dalla presentazione dai confini dell'assembly e che è quindi in grado di fare riferimento a qualcosa come System.Windows.Forms senza essere costretto ad aggiungere un riferimento (un'azione molto più che fa riflettere rispetto a una semplice clausola using) .

In situazioni come questa, non è inimmaginabile che il codice aziendale utilizzato da questo codice dell'interfaccia utente venga eventualmente riutilizzato.Qual è un buon modo per rifattorizzare i due livelli per consentire ciò?

Ho una certa familiarità con i design pattern, almeno in linea di principio.Tuttavia, non ho molta esperienza pratica, quindi sono un po' insicuro delle mie intuizioni.Ho iniziato a utilizzare il modello di strategia per questo.L'idea è identificare i luoghi in cui la logica aziendale richiama i componenti dell'interfaccia utente per porre una domanda all'utente e raccogliere dati, quindi incapsularli in una serie di interfacce.Ogni metodo su quell'interfaccia conterrà il codice orientato all'interfaccia utente dal flusso di lavoro originale e la classe dell'interfaccia utente implementerà quindi quell'interfaccia.

Anche il nuovo codice che intende riutilizzare la logica di business in questione implementerà questa interfaccia, ma sostituirà nuove finestre o eventualmente risposte prefabbricate o parametrizzate alle domande originariamente risposte dai componenti dell'interfaccia utente.In questo modo, la logica biz può essere trattata come una vera libreria, anche se con alcuni parametri di interfaccia passati ad alcuni dei suoi metodi.

È un approccio decente?Come dovrei procedere al meglio?Mi rimetterò alla tua saggezza collettiva su Internet.

Grazie!

Answer 1

Sembra che tu stia adottando un approccio buono, in cui si rompe le dipendenze tra elementi in calcestruzzo nella progettazione per, invece dipendere da astrazioni (interfacce). Quando si interrompe dipendenze in questo modo, si dovrebbe iniziare a utilizzare immediatamente unit test per coprire la vostra base di codice legacy e di evolvere il design con una migliore sicurezza.

Ho trovato efficace con il libro di lavoro Codice Legacy per essere prezioso in queste situazioni. Inoltre, non saltare a destra in modelli senza prima guardare ai principi di progettazione orientata agli oggetti, come il SOLID principi . Essi guidano spesso la scelta di modelli e le decisioni circa l'evoluzione del sistema.

Answer 2

Model-View -Controller - MVC ha un'alta probabilità di successo come una soluzione al vostro problema. Si separa vari logica, tanto come si descrive.

HTH

Answer 3

Lo affronterei identificando chiaramente le entità e le azioni che possono fare o che possono essere fatte nei loro confronti.Quindi, uno per uno, prova a iniziare a creare oggetti di logica di business indipendenti per coloro che effettuano il refactoring della logica fuori dall'interfaccia utente, effettuando la chiamata dell'interfaccia utente agli oggetti BL.

A quel punto, se comprendo correttamente il tuo scenario, avresti una manciata piena di oggetti BL, una parte dei quali ha effettuato chiamate a moduli vincenti, le chiamate a moduli vincenti dovrebbero essere promosse nel livello dell'interfaccia utente.

Quindi, come dice JustBoo, ​​penso che avrai una situazione sufficientemente distinta per iniziare ad astrarre i controller dal tuo BL e dall'interfaccia utente e far funzionare tutto in un progetto MVC.

Answer 4

Va bene, dato i vostri vari commenti, vorrei seguire il consiglio di Mr. Hoffa ed estenderlo. Sono sicuro che avete sentito problemi difficili dovrebbero essere suddivisi in unità sempre più piccole di lavoro fino a che non possono essere "conquistato".

Utilizzando questa tecnica, insieme con le metodologie di Rifattorizzare potrebbe risolvere i vostri problemi. C'è un libro e un sacco di informazioni sul web su di esso. Ora avete un link. Quella pagina ha una tonnellata di collegamenti alle informazioni.

Un altro collegamento dal autore del libro.

Quindi, si refactoring, lentamente ma inesorabilmente alla bontà cremosa di MVC, step-by-step.

HTH