Linee guida di progettazione per l'accesso ai dati

1

Sto lavorando su un'app (VB.NET) per la mia azienda che recupera i dati da un DB sui nostri prodotti (sensori) per effettuare misurazioni e calibrazioni.

Il DB è parte di un software che utilizziamo, quindi ho solo accesso in lettura e non posso modificarlo in alcun modo.

Al momento la soluzione è organizzata come segue:

  • BusinessLogic (DLL)
  • Entità (DLL)
  • DBAcess (DLL)
  • UI (WinForms)
  • Cartella test (con un progetto unittest per ogni progetto di soluzione)

In DbAccess ho solo una classe che è responsabile di recuperare i dati e anche di analizzarli, dal momento che ho bisogno di fare un po 'di lavoro, per preparare i dati recuperati per creare i miei oggetti di business (sensore e misuratore).

Devo refactoring questa classe in 2 come DbQuery e DbQueryParser o dovrei dichiarare il metodo "parsing" come condiviso e lasciarli nella classe?

A questo punto ho sempre problemi a riconoscere se sto rompendo l'SRP, dal momento che DbQuery è responsabile di recuperare i dati dal db, ma semplicemente recuperare i dati o recuperare i dati e restituirli nel modo in cui ho bisogno?

    
posta R. Gomez 22.07.2017 - 23:30
fonte

2 risposte

1

Avrebbe senso recuperare i dati e usarli senza analizzarli?

Avrebbe senso usare il parser su un dato che non è stato recuperato da DbQuery ?

Se rispondi di si ad almeno una di quelle domande, allora, in effetti, hai bisogno di due classi. Significa che il recupero e l'analisi sono azioni indipendenti, quindi non appartengono alla stessa classe.

Anche se non ho abbastanza informazioni sulla tua app, mi sembra che:

  • Non avrebbe molto senso recuperare i dati senza analizzarli. Le cose sarebbero diverse se tu avessi, per esempio, una funzione che scaricherà i dati da qualche altra parte, o la riverserà in un processo separato che potrebbe essere codificato in una lingua diversa e utilizzare un parser e tipi diversi.

  • Il parser, tuttavia, è relativamente indipendente dal recupero dei dati. Non solo hai bisogno di testare il parser dell'unità (e tu non puoi testarlo se è accoppiato con il codice di recupero dei dati), ma puoi anche decidere in seguito di scambiare il database corrente con uno diverso oppure modifica la tecnologia utilizzata per importare i dati (ad esempio query SQL dirette rispetto a ORM).

Ciò significherebbe che la tua intuizione era giusta e avrebbe migliorato il tuo codice per avere due classi invece di una.

Per disaccoppiare ulteriormente il parser dal retriever, assicurati che non si chiamino a vicenda. Il parser dovrebbe avere come input un gruppo di DTO da analizzare (o uno stream se applicabile al tuo caso), e come output un gruppo di oggetti di dominio che risultano dall'analisi. Appartiene al chiamante per chiamare prima il retriever e quindi il parser; il parser non dovrebbe chiamare il retriever né direttamente, né indirettamente attraverso l'iniezione di dipendenza.

    
risposta data 23.07.2017 - 00:11
fonte
1

Suggerirei di separare l'analisi dal recupero. Credo che il tuo istinto ti abbia già guidato. Ciò aderirebbe al modello di responsabilità unica. Al momento non è necessario il parser al di fuori dell'analisi di questi dati; tuttavia, separando ora, se hai mai avuto bisogno di cambiare il modo in cui i tuoi dati sono stati analizzati e / o recuperati, solo una classe deve cambiare. Inoltre, potresti trovare la necessità di riutilizzare il parser in futuro ed evitare inutili duplicazioni di codice perché avevi presto l'intuizione di codice per l'SRP.

    
risposta data 23.07.2017 - 11:10
fonte

Leggi altre domande sui tag