L'applicazione client-server con connessione diretta al database è una buona idea?

Tutto dipende dai requisiti del tuo sistema. Se hai 1-5 utenti che useranno solo l'applicazione internamente e c'è un dominio Windows, sì, un'applicazione fisicamente a due livelli è un progetto raffinato. Logicamente però vorresti codificare per n-tier, in modo che se tali requisiti cambiano puoi separare più facilmente i livelli fisici. È possibile utilizzare l'appartenenza al gruppo AD e connettersi al database utilizzando Integrated Security. Mappare il gruppo AD a un utente DB e concedere le autorizzazioni nel DB in base a tale ruolo / gruppo.

Avevo costruito un sistema del genere e funzionava bene. Fino a metà degli utenti avevano i loro uffici trasferiti nella posizione in un'altra città. Erano ancora logicamente parte della stessa rete in cui si trovava il DB, ma il tunnel VPN si trovava su una linea T1 molto lenta. L'app era inutilizzabile dalla nuova posizione. Fortunatamente avevo progettato la mia applicazione n-tier utilizzando il framework Csla.Net ed ero in grado di apportare alcune modifiche al file di configurazione, configurare un server app (server IIS) e il mio problema è stato risolto. Ciò ha reso la rete tra l'applicazione client meno chiacchierona, dal momento che gli oggetti di business si sono serializzati sul server dell'app, ha funzionato il db chatty (ei server DB e IIS erano sullo stesso switch di rete), quindi è stato serializzato nuovamente.

Ovviamente puoi fare lo stesso con WCF; dovresti solo costruirlo in questo momento e non preoccuparti di questo, ma ci sono più costi iniziali per la creazione del servizio WCF. Tuttavia, saresti preparato se i requisiti cambiano e la chattiness del codice DB diventa un problema. Puoi anche utilizzare viste e altri oggetti DB come necessario per proteggere, anche se ho trovato SP che sono solo involucri sottili attorno alle istruzioni di inserimento / aggiornamento / cancellazione per avere più manutenzione di quanto valga.

Non c'è una risposta chiara a questa domanda senza saperne di più sulla tua applicazione.

Non c'è quasi nessuna differenza riguardo la gestione degli utenti.

Il punto molto più importante è: hai bisogno di transazioni a lungo termine ?
Se è così, l'architettura 2 livelli è più facile da costruire. Altrimenti la maggior parte dei framework supporta l'architettura 3 livelli che consente la logica di business in un punto centrale ma al di fuori del database.

"I have concern about logging requirement, how to stop bad actors connecting directly to DB and adding record as someone else (insert other ID)."

La soluzione a ciò risiede nella buona progettazione del database: non lasciare che i tuoi utenti accedano direttamente alle tabelle nel tuo database.

Fornire l'accesso tramite visualizzazioni . Quando l'utente esegue DML contro di essi è possibile modificare, aggiungere o rimuovere campi come richiesto dal modello di sicurezza. Per esempio. puoi sostituire il "userid" che l'utente ha passato con il suo DML dallo UserId preso dalla sessione reale del database.