La mia domanda riguarda il modo migliore per organizzare le classi C ++ attorno a un database modello, e capisco che questo possa sembrare molto elementare.
Il software che propongo di creare farà quanto segue. È inteso per piccoli produttori di FMCG e useranno Qt.
- Il software registra i reclami relativi a prodotti non conformi, azioni correttive e servono come tenuta di registri elettronici
- Ci sarà un bel po 'di logica di business, come lo standout La funzione è intesa come reportistica completa, ricerca e analisi, così come un approccio flessibile per l'inserimento di dati per lisciare flussi di lavoro (vale a dire una pausa dal "uno schermo per fase del processo" paradigma)
- L'archivio persistente è un database SQL, con una tabella (s) per ciascuno tipo di record (alcuni record verranno suddivisi in tabelle separate per Indagini / soluzioni. Ciò significa che la maggior parte del lavoro verrà eseguita su a riga singola).
- Ogni cliente che utilizza questo software richiederà modifiche, colonne / campi aggiuntivi o modifiche nei nomi delle colonne e forse logica di business. Ogni cliente può richiedere aggiornamenti che cambiano il struttura del database. L'idea è che tutto ciò che può essere personalizzato, qualsiasi i requisiti specifici del cliente vivranno all'interno di queste classi.
- Ci saranno segnalazioni, che riguardano principalmente la raccolta di record corrispondenti categorie particolari, ricerche di parole, ecc.
Ho lo schema del database fatto e preparato, e la logica di come le tabelle riferirsi è chiaro. Ho usato questo schema in un altro framework, ma un'applicazione web non sembra offrire il livello di potenza per l'utente per quanto riguarda la GUI, che è essenziale per differenziare questo prodotto dagli altri.
La mia domanda è come progettare le classi attorno al database. È importante ottenere questo giusto, in modo che l'architettura del software non deve essere riprogettato in seguito. Le classi non saranno responsabili per il persistente negozio, solo per agire come intermediario tra il livello responsabile l'archivio persistente e i controller / viste.
L'approccio più logico sembra essere quello di avere una classe per non conformità / reclami ecc., che memorizza solo l'istanza (cioè un oggetto per record di non conformità), convalida i dati e la logica di business specifica della classe (es. ). Una classe per tabella sembra logica in questo caso. Quello con cui sto combattendo è se sia una pratica standard avere semplicemente membri di dati per ogni colonna, definire getter e setter, o se dovrei creare una classe che non è codificata per mappare una tabella, ma che popola una mappa basata sullo schema del database o sul file esterno che definisce le proprietà del database e della colonna. Il primo significa che la codifica per la classe deve essere modificata quando le colonne vengono modificate, il secondo potenzialmente no. Tieni presente che, per la maggior parte del tempo, ogni utente lavorerà con un record alla volta.
In breve, posso vedere un esempio di come eseguire query SQL, ma ho faticato trova tutto ciò che mi mostra come dovrebbe apparire la classe (o se l'intero approccio è sbagliato) e mi piacerebbe confrontare quello che sto facendo, con quello che l'industria definirebbe una buona pratica (non sono un programmatore di commercio).
Grazie,