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?