Attualmente sto lavorando con un sistema che funziona come un bus dei messaggi. Un messaggio arriva al servizio (servizio Windows WCF ospitato). Il sistema utilizza quindi un modello di localizzazione del servizio per cercare quale assembly caricato dinamicamente verrà assegnato al messaggio. L'assembly viene trovato e quindi viene eseguito un metodo che gestisce il messaggio. La risposta viene quindi inviata al client.
Il problema è che la base di messaggi sta crescendo enormemente, così come i loro plugin associati. E c'è molta duplicazione del codice. Lasciatemi fare alcuni esempi:
- GetOrderMessage
- GetExpiredOrderMessage
- GetOrderMessageByCustomerId
- Get_something_related_to_order_Message etc, etc...
Come puoi vedere, i messaggi sono molto specifici. I messaggi stessi sono semplici contratti di dati e contengono zero business logic.
Oltre a questo problema, c'è un plug-in per alcuni di questi messaggi che gestisce solo un messaggio. Pertanto, c'è quasi un plugin per ogni tipo di messaggio !! Il sistema sembra supportare una relazione uno-a-molti per un messaggio / plug-in, ma sembra che tutte le implementazioni siano individuali.
Come potrei refactoring questi per ridurre la duplicazione del codice e rendere il sistema più intelligente? Vorrei che il codice venisse digerito più facilmente agli sviluppatori perché si verificano molte duplicazioni.
(A causa di alcuni vincoli, non posso usare un ORM per l'accesso ai dati / la creazione di entità)
In risposta al commento di Robert Harvey di seguito, vorrei chiarire quanto segue:
Nel 99% dei casi d'uso, il plug-in layer si limita semplicemente a racchiudere una chiamata di accesso ai dati. Ecco come potrebbe sembrare.
Request of GetOrderMessage ->
Order Plug-in ->
Order Data Access (ADO.NET, hand-rolled stored procedure of usp_GetOrder) ->
value returned from Order Plug-in ->
Response of GetOrderMessage returned to client