Se i trigger di database sono il male, è anche il male per avere effetti collaterali quando si imposta una proprietà in Java o C #?

Question

Supponiamo che [trigger del database sono il male]. 1

Questo significa che gli effetti collaterali quando si imposta una proprietà su un Java o C # oggetto sono anche il male?

Mi sembra che esistano tutti gli stessi problemi.

Answer 1

Andando contro il grano qui ...

Proprietà NON deve innescare effetti collaterali. Questo è ciò che il metodo di sono per.

Per avere proprietà causare effetti indesiderati si finisce in una situazione fosse codice è essenzialmente nascosto. Le persone raramente si aspettano di immobili da dare il via qualche processo o causa qualcos'altro da capovolgere. Se questo deve essere documentata, quindi non la sua evidente e soggetto ad essere ignorato.

Tuttavia, ci aspettiamo che accada qualcosa quando chiamiamo un metodo.

Prendendo l'esempio di @ Astander, dice che l'atto di cambiare "Prezzo" dovrebbe causare una proprietà diversa "costo" per il cambiamento. Tuttavia, quello che se abbiamo poi aggiungere una nuova proprietà denominata "sconto"? Il codice intorno alle proprietà prezzo e importo dovrebbe cambiare. Che non è molto rilevabile.

Tuttavia, se il costo si calcola .. allora tutto è meglio.

Answer 2

Non necessariamente, no. Se si dispone di una Price o proprietà Amount, e si modifica che, sembrerebbe che il Cost dovrebbe cambiare di conseguenza?

O c'è qualcosa di diverso che si aveva in mente con questo annuncio?

Answer 3

No. Molte proprietà possono e devono innescare effetti collaterali.

Esempio: Immaginate due elementi visivi in ??cui un bambino è contenuta all'interno di un genitore. Impostazione parent.Visible = false dovrebbe probabilmente anche impostare child.Visible = false.

Spesso questi effetti collaterali sono rese esplicite attraverso un evento (System.Windows.Forms è piena di eventi PropertyChanged) o un'interfaccia (ad esempio INotifyPropertyChanged).

Answer 4

Per quanto utile come proprietà a volte sono, fanno introdurre alcune incertezze nel giorno per giorno di codifica in un ambiente della squadra, in cui non tutti interpreta necessariamente l'uso di scopo e appropriato delle proprietà nello stesso modo.

Questo è uno di una serie di questioni che sorgono:

• dovrebbe setter di proprietà hanno non evidenti effetti collaterali.
• dovrebbero fare di elaborazione potenzialmente intensivo?
• campi pubblici hanno ancora un posto, o dovrebbero essere tutti i campi privati ??/ protetti e vi si accede tramite le proprietà? Questo può avere un impatto quando fanno uso di riflessione:. Può essere utile sapere che non devi mai cercare insieme Fields di un tipo

In definitiva, ritengo che i punti sopra 2 non contano tanto finché eventuali effetti collaterali o potenzialmente costose operazioni sono documentate, perché lo stesso dovrebbe valere per metodi pure.

I più ipotesi si può tranquillamente fare il codice riduzione della complessità, ma che il guadagno è negato in una certa misura da spese generali di comunicazione supplementari. Funziona solo fino a quando tutta la squadra è sulla stessa pagina, e soggiorni sulla stessa pagina.

A volte penso proprietà causare più problemi di quanti ne risolvano.

Answer 5

Beh dipende. Certamente ci sono effetti collaterali, che porterà l'utente di sorpresa ed è meglio evitare quelli IMO.

Io preferisco che le proprietà si comportano molto come i campi, dal momento che lo stesso aspetto dal punto di vista del lettore (in C # in ogni caso). Se una proprietà avrebbe alcun effetto collaterale non ovvio, preferirei un metodo su una proprietà.

Answer 6

In aggiunta ai commenti di Chris di cui sopra, che sono d'accordo con c'è un altro aspetto che ha contribuito ai trigger di essere considerato un po 'subdolo e che è il fatto che essi non sono - evidenti.

Questo rende quindi molto facile dimenticare che a sua volta li rende molto difficile il debug.

La gente (e io sono uno di loro e non l'unico di sicuro) hanno trascorso ore cercando di problemi di debug e passando attraverso l'inizio del flusso fino alla fine (procedure ovvero di database di fascia apparente / query DML) di realizzare ciò che stava causando il problema tutti insieme sono stati i fattori scatenanti -. a causa loro intrinsecamente essere operazioni in background

Si potrebbe anche sostenere che la corretta registrazione dei trigger dovrebbe comportare facile evitare questo tipo di problema, ma di solito la registrazione è mai fatto nello strato database stesso quindi complicare questo aspetto della risoluzione di un po 'di più.