Come disaccoppiare e riutilizzare la logica di persistenza, la logica dell'interfaccia utente e la logica di business tra progetti software embedded

1

Ho lavorato nel settore dei dispositivi embedded più di 5 anni come ingegnere software. La maggior parte delle volte i nostri produttori di hardware forniscono un kit di sviluppo software per le loro schede di riferimento. Sono principalmente dispositivi embedded Linux.

Il problema è che la maggior parte delle volte troviamo che le interfacce di gestione (Web UI, CLI, SNMP ...) sono strettamente accoppiate con il database che memorizza la configurazione persistente del dispositivo e anche le interfacce eseguono ognuna nella propria operazioni per applicare la nuova impostazione al sistema. Ad esempio, quando l'utente aggiorna lo stato del firewall tramite l'interfaccia utente Web, il server Web esegue automaticamente le chiamate alla funzione C system () utilizzando le regole di iptables come argomento. Ci rende molto improduttivi perché:

  1. Non possiamo riutilizzare componenti coesivi in nuovi prodotti. Le specifiche per i nuovi prodotti stanno diventando sempre più esigenti e il sistema embedded è costoso da sviluppare.
  2. Le interfacce di gestione non sono coerenti e il codice viene ripetuto tra di loro.
  3. Poiché il codice è strettamente accoppiato e l'astrazione non è buona, lo stesso vale per le attività. È difficile parallelizzare le attività se lo sviluppatore di una nuova funzionalità dovrebbe conoscere il server Web o il responsabile del server Web dovrebbe conoscere i dettagli di un'implementazione della funzionalità.
  4. Non possiamo testare i componenti ma l'intero sistema.

A volte le interfacce di gestione chiamano API del database per memorizzare nuove impostazioni e dopo di ciò chiamano la stessa funzione che legge le nuove impostazioni di funzionalità dal database e applica le nuove impostazioni nel sistema. Penso che non sia ancora una buona soluzione, ma mi piacerebbe sentire opinioni su questo design.

Ora stiamo cercando di rompere il software in componenti responsabili che possiamo riutilizzare in nuovi prodotti. Ad esempio vorremmo utilizzare gli attuali servizi di dispositivi incorporati nei nuovi prodotti e vorremmo anche avere interfacce utente che possiamo facilmente adattare per una nuova specifica.

Come ingegnere del software sono consapevole delle conseguenze di una cattiva astrazione, di una bassa coesione e di un cattivo incapsulamento nella progettazione del software, ma non ho una buona conoscenza dei modelli di progettazione. Questo è il nostro piano:

  1. Creato un set di funzioni C per i servizi del dispositivo che possono essere richiamati dalle interfacce utente, esponendo un'interfaccia che nasconde tutti i possibili dettagli di implementazione dall'utilizzo del servizio. Ci saranno funzioni per cambiare l'orario del sistema, per gestire i GPIO, per cambiare lo stato del firewall ...
  2. Queste API dei servizi si prenderanno cura della persistenza dei suoi dati utilizzando l'API del livello di persistenza.
  3. Le interfacce utente recuperano e impostano nuove impostazioni utilizzando questo set di funzioni dei servizi API.
  4. Ogni API di un servizio esporrà una funzione x_initialize () in modo tale che quando il sistema avvia una applicazione manager di avvio può chiamare questa funzione per ciascun servizio. Queste funzioni recuperano le impostazioni per il servizio dal database e le applicano al sistema chiamando le altre funzioni della propria API di servizio.

Non mi piace molto il punto 4 sopra perché somiglia molto alla situazione che abbiamo ora dove le interfacce utente memorizzano nuove impostazioni nel database e chiamano una grande funzione nessuno sa cosa funzioni questa funzione finché non viene vista la i dettagli di implementazione (e l'aspetto dei dettagli di implementazione di una funzione sono per me un cattivo sintomo).

Sto cercando informazioni sui modelli di progettazione per riutilizzare e separare le preoccupazioni come livello persistente, interfaccia utente e logica degli oggetti di business o di dominio (non sono molto sicuro di utilizzare concetti validi come oggetti di dominio). Vorrei una spiegazione con esempi concreti che potrei capire meglio.

    
posta MABC 05.03.2016 - 20:51
fonte

1 risposta

1

Ciò che cerchi è un framework in stile MVC che viene eseguito sul tuo sistema operativo di destinazione. link

Il modello è molto antico, molte varianti e strutture sono in costante evoluzione e nuove sono state sviluppate. Quindi, tutto ciò che mi permetto di fare è generalizzare un po ': il modello in MVC ha i dati protetti e persistenti della tua azienda / dominio logico (il che significa che non dovrebbe consentire di archiviare qualcosa di errato), la vista gestisce il rendering di vari elementi del modello all'interfaccia utente e il controller gestisce l'associazione e l'inoltro dei comandi dai controlli dell'interfaccia utente al modello (richieste di apportare modifiche) e / o la visualizzazione (ad esempio comandi che richiedono di cambiare visualizzazione). Un buon framework MVC può rendere più facile il lavoro a un livello più alto, quindi non ti troverai a ripetere l'impianto idraulico.

Come ho già detto, il pattern MVC è piuttosto vecchio ed è stato originariamente sviluppato per supportare lo sviluppo di applicazioni desktop basate sull'interfaccia utente. In quanto tale, non ha tenuto conto direttamente della persistenza nel modo in cui pensiamo oggi (ovvero che tutte le modifiche vengono automaticamente mantenute, invece è previsto che l'utente apra i file e li salvi in seguito). È sensato separare il modello in una parte orientata alla persistenza e una parte orientata alla business logic (che non garantisce riferimenti pendenti, ad esempio, e impone altri requisiti del modello di dati).

(Inoltre, dal momento che stai usando un database, puoi cercare in ORM per aiutare con persistenza e mappatura della persistenza agli oggetti e viceversa.)

Stai sicuramente ponendo le domande giuste, quindi continua a cercare le astrazioni comuni che puoi utilizzare nei vari progetti. Mi piace quando il codice si legge bene perché è di alto livello e usa le giuste astrazioni, che si prendono cura di se stesse senza dover spesso immergersi più a fondo. Il codice ben stratificato è molto più facile da utilizzare. L'idea è che tu crei i livelli introducendo un'API di livello superiore e poi quando un livello sopra lo utilizza, quel livello non raggiunge o aggira il livello inferiore successivo per parlare con un livello ancora più basso. Quando lo ottieni, puoi gestire molte più righe di codice rispetto a quando tutto è, forse, modulare, ma allo stesso livello.

Non sono molto aggiornato sui framework MVC o ORM di Linux, ma penso che sia qui che dovresti cercare.

    
risposta data 05.03.2016 - 21:57
fonte