È una buona pratica separare i gestori e le query del database in classi diverse?
Ci sarà una classe separata contenente tutti i gestori di eventi necessari e ci sarà anche un'altra classe per le query del database?
È una buona pratica separare i gestori e le query del database in classi diverse?
Ci sarà una classe separata contenente tutti i gestori di eventi necessari e ci sarà anche un'altra classe per le query del database?
Assolutamente sì , il tuo codice dovrebbe (quasi) avere sempre una separazione dei dubbi :
In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity of programming and encapsulation (or "transparency" of operation), with the help of information hiding. Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer).
Ci sono un sacco di filosofie e schemi di progettazione del software, ma il Principio di Responsabilità Unica (SRP) è probabilmente un buon valore predefinito da utilizzare sempre:
In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.
La traduzione approssimativa è: "La tua classe / metodo / funzione dovrebbe fare una cosa e farla bene"
+1 per la risposta di Emmad Kareems, ma vorrei anche aggiungere che le query del database dovrebbero essere implementate (se possibile) come stored procedure nel database perché sono più facili da testare / debug dell'unità (perché è possibile eseguirle senza il codice ). Rendono il cambiamento più semplice poiché per alcune modifiche è sufficiente modificare la procedura e non la base di codice. Funzionano anche più velocemente perché il motore DB li pre-compilerà e memorizzerà statistiche su di esse che probabilmente non farà per le query che sono codificate nella tua app.
E sì, l'approccio di N teir funziona con qualsiasi linguaggio tu voglia - anche linguaggi di scripting - hai solo bisogno di trovare il pattern / codice / libreria corretto per la situazione.
La risposta alla tua domanda è Sì. È una buona idea separare l'applicazione in classi, componenti e livelli. Una separazione più sofisticata può essere ottenuta utilizzando una famosa architettura di progettazione chiamata N-Tier Architecture in cui un'applicazione fisicamente separa i suoi componenti in livelli fisici separati (non solo livelli logici). Ha molti vantaggi che ti consiglierei di sapere se non lo hai già fatto. Vedi ad esempio questo:
Un altro modello di design famoso che promuove una maggiore indipendenza della GUI (Wikipidia lo considera un'architettura) è MVC (Model-View-Controler) - Vedi a riguardo qui:
Potrebbe anche essere utile una discussione su N-Tier e MVC - Vedi questo:
Prima di utilizzare una di queste cose, è necessario giustificare lo sforzo e il costo della curva di apprendimento. Le applicazioni N-Tier e MVC possono essere classificate come tecniche di programmazione "avanzate" e possono essere più difficili per chi non ha familiarità con i concetti, quindi vale la pena?
Leggi altre domande sui tag programming-practices java user-interface