Quando è accettabile che la logica aziendale venga esposta su applicazioni distribuite?

1

Quando si sviluppano applicazioni (per semplicità, utilizzare un modello client-server) destinate a essere implementate sui sistemi dei clienti, quando è accettabile esporre la logica di business al di fuori del codice compilato (ad esempio nelle stored procedure)?

Ero abituato a sottoscrivere il pensiero che ogni e tutta la logica dovrebbe essere sempre all'interno del codice compilato in quanto è protetto da eventuali alterazioni oltre a fornire un livello di protezione IP. Tuttavia, dopo aver distribuito alcune piccole applicazioni specifiche del client basandosi su stored procedure, ho scoperto che la possibilità di apportare correzioni / aggiustamenti specifici del cliente "al volo" (in modo responsabile, ovviamente) direttamente in SQL ha reso sia il supporto che la manutenzione in modo significativo più facile e veloce come un cambiamento non deve essere compilato.

Comprendo gli svantaggi di questo approccio:

  • Chiunque abbia i diritti di DB potrebbe cambiare il comportamento / rompere il applicazione senza che tu sappia
  • Difficoltà nel controllo della versione
  • Alcune perdite di protezione IP

Supponendo che la piattaforma sarà sempre la stessa (non è necessario supportare più DB SQL) e l'applicazione potrebbe essere distribuita da più client distinti, è logico - da una prospettiva di sviluppo e di business - consentire alla logica aziendale di esistere da qualche parte è relativamente facile da visualizzare e modificare?

    
posta Jason Faulkner 28.09.2014 - 20:25
fonte

1 risposta

0

Anybody with DB rights could change the behavior/break the application without you knowing

C'è una protezione relativamente semplice da questo: basta scrivere nel tuo contratto che non appena qualcuno manipola il tuo prodotto, ti rifiuterai di fare qualsiasi altra manutenzione. Aggiungi anche una nota che con ogni nuova versione del tuo software sostituirai le stored procedure esistenti con le nuove versioni. Ciò impedirà alla maggior parte dei clienti di cambiare le cose che non dovrebbero cambiare.

Version control difficulties

Perché dovrebbero essere diversi da quelli per il codice lato client? Poiché hai scritto che è un prodotto standard, devi separare rigorosamente le modifiche / i parametri specifici del cliente dal codice sorgente del tuo prodotto. Non c'è alcuna differenza generale per il codice client o il codice lato server in questo. Quando segui questa regola, il controllo della versione per il tuo codice lato server dovrebbe essere semplice o difficile come per il tuo codice lato client.

Some loss of IP protection

Non lo sopravvaluterei. Finché non c'è un "algoritmo rivoluzionario e totalmente ingegnoso" nascosto nelle procedure memorizzate, suppongo che il codice non sia di gran valore per nessuno finché non ha anche il codice sorgente lato client della tua applicazione. Inoltre, per alcuni sistemi di database ci sono anche opzioni disponibili per nascondere o offuscare le stored procedure - Google è tuo amico.

Quindi il succo è: prova ad affrontare il tuo codice lato server nello stesso modo in cui gestisci il tuo codice lato client, quindi i tuoi "svantaggi" svaniranno.

    
risposta data 28.09.2014 - 21:19
fonte

Leggi altre domande sui tag