Se stai utilizzando un linguaggio OO con polimorfismo, dovrebbe essere già chiaro dalle firme del metodo quale metodo devi chiamare:

bool SaveCustomer(Customer cust)
{
    var conn = new DatabaseConnection(connectionString);
    SaveCustomer(conn, cust);
}

bool SaveCustomer(DatabaseConnection conn, Customer cust)
{
    // Save the customer
}

Correggi il modello, non i muri

Percepire la necessità di avere questi marcatori sembra un odore di codice . Non mi sembra una questione di convenzione di denominazione ma di design architettonico (e comportamentale). Anche se ovviamente avere una buona convenzione di denominazione sarà importante per rendere utilizzabile quel design.

Soluzioni

Ci sono vari approcci, ma qui ci sono 2 opzioni possibili.

1 Class per DB Usage Approach ^{(facile da fare, ma non raccomandato)}

Avere 2 classi separate per affrontare entrambi gli scenari, in modo efficace prendendo la distinzione di un livello più in alto nella catena. Ad esempio, qualcosa di simile (in nessuna lingua particolare):

class CustomerDirectDAO {

  save() {}

}

class CustomerIndirectDAO {

  save(Connection c) {}

}

Come accennato, questo ti consentirebbe di affrontare il problema della selezione del problema giusto a un livello superiore della catena di progettazione. Tuttavia, puoi ovviamente sembrare noioso e hai ancora bisogno di una distinzione per ogni approccio. Inoltre, la prima classe probabilmente fa essenzialmente ciò che la seconda classe fa con il passo in più per creare la connessione e invocarla.

Questo non è eccezionale.

1 Data Class e 1 DB Connection Supplier / Factory

Sarebbe meglio avere una classe che richiede sempre di passare un oggetto di connessione e un'altra classe che li costruisce e li fornisce. Sembrerebbe un modo migliore e consentirebbe di scambiare le implementazioni degli oggetti di connessione che potrebbero provenire da diversi fornitori.

Un wrapper L'oggetto Connection può anche essere fornito una sola volta al costruttore, dove il wrapper controlla lo stato della connessione e ne ricrea uno se necessario.

Ad esempio (in nessuna lingua particolare):

class Customer {

  save(ConnectionWrapper c) {}

  // (or pass the wrapper object only once to the constructor,
  // as the wrapper would automatically check to reconnect the
  // connection if invalid)

}

class ConnectionWrapper<T extends Connection> {

  T get() {}; // gets the wrapped connection or returns a newly created one

}

class ConnectionFactory<T extends Connection> {

  ConnectionWrapper<T> create() {}

}

Ci sono dozzine di modi per raggiungere questo obiettivo e puoi scegliere quello che sembra più applicabile a te.

L'approccio sopra riportato utilizza una singola classe di rappresentazione dei dati che consente di cambiare classe utilizzata per l'archiviazione. Ma un altro approccio è quello di prendere il problema dall'angolo inverso, per instnace con questo DAO schema , in cui è possibile visualizzare un approccio simile per consentire implementazioni swappable del back-end senza utilizzare i prefissi dei metodi, ma richiedono 2 implementazioni concrete del proprio oggetto dati:

Maggioriinformazionisull'argomentoconapprocciper DAO su Wikipedia e DAO per JEE applicazioni.

L'uso dei prefissi o dei suffissi nei nomi dei metodi può essere utilizzato in alcuni casi in modo significativo per esprimere le intenzioni progettuali direttamente nel codice. Non lo consiglierei comunque, dato che idealmente dovrebbe esserci un documento aggiuntivo dove sono documentate, tra le altre cose (ad esempio viste architettoniche differenti) le decisioni di progettazione. Un'eccezione sono i pattern di denominazione ampiamente accettati, ad esempio usando + Factory per le classi coinvolte nel pattern Factory.

Nel tuo caso con le funzioni wrapper, hai nel primo caso due responsabilità in un unico metodo, ovvero stabilire una connessione e salvare il cliente. Perché non denominare il metodo di conseguenza bool ConnectDBandSaveCustomer(Customer cust) . Questo è espressivo per ciò che il metodo effettivamente fa e già si vede che deve essere un metodo wrapper poiché è possibile derivare le due responsabilità direttamente dal nome del metodo.

Certo, può portare a nomi di metodi lunghi e quindi a una sorta di codice gonfio, ma a chi importa se riesci a capire il codice estero con una magnitudine più veloce . Inoltre, ti rende più produttivo nell'usare un altro codice, ad esempio negli IDE con completamento automatico, perché non dovrai guardare tanto spesso nella definizione del metodo come dovresti con nomi di metodi scarsamente scelti!

Questo è in realtà piuttosto soggettivo e si riduce davvero a ciò che l'individuo preferisce. Dipende anche dalle dimensioni del progetto.

In un progetto più ampio che coinvolge un gruppo di persone è sempre buona norma standardizzare uno standard di codifica per tutti i membri del gruppo da seguire (baco per il direttore tecnico, se necessario).

Ci sono un buon numero di standard per le aste là fuori. Uno dei più noti è la notazione ungherese che aggiunge un prefisso a tutto.

Wiki: Hungarian_notation

Esempi:

boolean bDone;
double * pdbPointerDouble;

Puoi anche creare una nuova varietà tutta da te (che personalmente preferisco) io personalmente uso solo il camelCase e alcuni standard auto dichiarati. Come una notazione HeadedCamel per funzioni e senza testa per variabili. di cos puoi anche aggiungere prefissi o suffissi. ma il punto principale di questo è di mantenerlo semplice e facile da capire.

Wiki: CamelCase

Esempi:

boolean isTriggered;
void TriggerFunction()
{
    // code here
}

Trova una notazione adatta a te (e ai tuoi compagni di squadra) e dovresti essere bravo a farlo.

Spero che questo aiuti

P.S. maggiori informazioni: link