Due quesiti.
1. Ho sempre cercato di sviluppare secondo i criteri MVC, separando bene il model dal view e dal controller. In particolare, presumo che la parte di cui stiamo parlando rientri nel model (ossia la parte che tra l'altro racchiude tutte le query), o mi sbaglio? Ovvero, mettere tutto in viste (o, come mi consigli, lasciare perdere anche quelle per passare TUTTO, selezioni ed aggiornamenti, alle stored procedure) non significherebbe passare al db la parte del model e quindi non rispecchiare più quel criterio? Te lo chiedo anche perché a breve avrei avuto in previsione di studiare Hibernate, che mi dicono essere un ottimo ausilio proprio per quella parte. Quindi due sono i casi:
1A. se dovessi lasciar fare tutto alle st. procedure Hinernate sarebbe del tutto inutile e la parte model passerebbe in toto al db
1B. Le stored procedure vanno comunque richiamate, l'applicazione continuerebbe a rispettare i criteri MVC, solo che ora il lavoro sarebbe spartito tra applicazione e database. Diciamo un MVC più efficiente, e non avrebbe senso smettere di studiare Hibernate, visto che mi tornerebbe comunque utile.
Quale dei due, 1A o 1B?
2. Come da primo quesito, vorrei evitare che qualche amministratore di rete possa maldestramente modificare i dati dall'interno del db con evidenti conseguenze negative (tutti i sistemi di collegamento e storicizzazione gestiti dall'applicazione saltati, ecc). Se impostassi un bel trigger, anche eseguendo modifiche dall'interno del db ne resterebbe traccia nella famosa tabella di log. Ma se poi questa persona riuscisse ad accedere anche alla tabella di log, nascondendo magari la sua maldestra operazione eliminando la riga del relativo log... Non c'è proprio il modo di nascondere un oggetto, ovvero di non renderlo nemmeno accessibile all'amministratore del database ma solo alla mia applicazione?
