Suggerimenti di architettura su una 'intranet' multi-progetto multi-database

Question

Suggerimenti di architettura su una 'intranet' multi-progetto multi-database

#1 da (5 voti)
#2 da (3 voti)
#3 da (0 voti)
#4 da (-2 voti)

6

Ecco la situazione che ho ereditato:

Abbiamo circa 10 siti web (moduli web di Asp.net) ciascuno con il proprio database.
Ciascuno di questi database contiene alcuni dati specifici del sito e ognuno ha una forma di una tabella utente che verrà mappata a ciò che viene chiamato un servizio utente.
Il Servizio utenti è solo un altro sito Web che dispone di un database con una tabella (Utente) con circa 3 identificativi univoci diversi per un utente: un Guid UserId, un ID applicazione desktop interno (app di terze parti, necessaria per eseguire il mapping a it) e un nome utente.
Su tutti i diversi siti Web i database hanno la tabella Utente, a volte chiamata Persona, o Studente, o qualsiasi altra cosa, e sono incoerenti in cui UserService.Utente. [IdentifyingColumn] mappano a.

Il problema:

Sta arrivando al punto in cui queste applicazioni ora hanno bisogno di condividere alcuni dati tra loro, e vedo che è necessario aumentare man mano che i reparti sono razionalizzati ancora di più. Con questo set up corrente, è un sacco di salto del telaio per ottenere la colonna UserId giusta da abbinare alla colonna UserId corretta nel UserService.

Confuso ancora? Anche a me ..

La domanda:

Come affrontare la correzione del problema? Ho alcune idee diverse, alcune mi piacciono più di altre, ma per implementarle ho bisogno di alcuni solidi vantaggi che posso portare a capo dell'IT, oltre a giustificare i tempi di programmazione necessari per la riscrittura.

Idea 1: crea una vera applicazione intranet. Un'applicazione web con un database. In questo modo vivono tutti nello stesso progetto e la condivisione dei dati tra i vari reparti è molto semplice e veloce.

Idea 2: Crea un campo identificativo "Chiave master" che sarà il fine a tutti per identificare un utente. Rendi questa chiave disponibile su ogni database e quindi non ci sarà alcuna mappatura dispari e i vari siti potranno parlarsi. Per me questo risolve un problema, mappando ogni db a quello successivo. È ancora molto frammentato e il riutilizzo del codice è molto limitato.

Idea 3: lavora con esso nella forma attuale cercando di continuare la moda attuale di molti piccoli database e siti.

Quale delle opzioni sopra indicate suggeriresti e perché?

architecture code-reuse asp.net application-design sql-server

posta ledgeJumper 13.03.2013 - 16:26

fonte

4 risposte

5

Lo scenario che descrivi è perfetto per un servizio Single Sign-On. Esistono diversi percorsi che è possibile seguire per una soluzione:

Hai detto che questo è per una Intranet. Supponendo che si stia utilizzando Windows Server per la sicurezza, si dispone di tutto ciò che è necessario per una soluzione Single Sign-On. Le tue applicazioni possono utilizzare Autenticazione di Windows e gli utenti nel dominio verranno automaticamente registrati dopo aver navigato sul tuo sito.
OAuth è un'altra opzione per la creazione dell'infrastruttura che hai menzionato (un'applicazione fornisce informazioni a un'altra basata sulla fiducia stabilita da un provider di identità). Ancora una volta, Microsoft fornisce una soluzione OAuth chiamata Windows Identity Foundation (WIF) che fornisce l'infrastruttura per ciò che è chiamate applicazioni "Claims Aware".
Servizio di controllo di accesso di Windows Azure / Active Directory è un'opzione se vedi la necessità di esporre il tuo applicazione al pubblico. Sarai anche in grado di configurare la tua app in modo da accettare accessi da fornitori di terze parti come Facebook, Account Windows (precedentemente Live ID) e Twitter.

L'uso di questi come base per la gestione delle identità ti consentirà di concentrarti maggiormente sulle parti importanti della tua applicazione.

risposta data 13.03.2013 - 17:12

fonte

0

Supponendo un ambiente di dominio Windows, l'autenticazione di Windows sarebbe di gran lunga il modo più ragionevole di andare.

A meno che i siti e i database siano tutti molto piccoli, eviterei di avere 1 sito / database unificato per tutti e di tenere i siti tutti separati per un paio di motivi:

evita i tempi di inattività per tutti i sistemi se hai solo bisogno di cambiare un sistema
diversi team possono lavorare separatamente su diverse app

risposta data 13.03.2013 - 17:27

fonte

-2

Credo che tu stia utilizzando il vecchio database RDBMS (come SQL 2008)

ti suggerisco di utilizzare ORDBMS (Oracle 10g o 111g) che può funzionare in modo più efficiente specialmente per questi tipi di grandi quantità di dati utilizzando l'istanza singola per database multipli in grado di condividere dati.

Puoi condividere altri dati della tabella usando * Object_User.table_name * nella tua stessa tabella tutti quei database condivideranno un'istanza (connessione) come un singolo servizio SID.

In questo modo puoi connetterti con qualsiasi dataab utilizzando una singola connessione. per ulteriori ricerche visita =
Sito web Oracle Sito Web Oracle per database multipli o rispondere per ulteriori discussioni ....

risposta data 03.04.2013 - 14:27

fonte

Leggi altre domande sui tag architecture code-reuse asp.net application-design sql-server

Gestione delle dipendenze GPL opzionali Metodologie per la gestione degli utenti e dell'accesso?

score 3 · Accepted Answer

Single Sign On è un'idea eccellente. Solo così sai, non è necessario utilizzare una tecnologia specifica, come Active Directory, WIF o OAuth. puoi implementarlo con l'autenticazione di moduli ASP.NET. Ecco come lo fai:

Vendendolo alla testa dell'IT

Non rendete la felicità dello sviluppatore, vi è un vantaggio significativo per la felicità degli utenti di SSO.
Prendi il tuo carico di lavoro corrente e proietta il tempo necessario per continuare a lavorare con un sistema imperfettamente progettato per un anno. Confrontalo con il tempo richiesto per fare una riscrittura. Il più delle volte, se si rompe anche dopo un anno, è un buon scambio.

Decidere su come

Scopri il modo più comune in cui gli utenti sono identificati (come il nome AD o l'indirizzo e-mail) e cerca di centralizzarlo - dovrebbe ridurre l'ambito della riscrittura.
Una volta definita la migliore chiave, scegli una tecnologia o un metodo che la sfrutti.

Suggerimenti casuali della mia esperienza

Ho avuto il minimo attrito con OAuth. Soprattutto perché abbiamo utilizzato le app di google, quindi tutti avevano già un account google aziendale.
L'autenticazione di Windows ha problemi a seconda che sia configurata con NTLM o Kerberos - Ho avuto un problema particolare con NTLM su una VPN.
ADFS era troppo complicato per funzionare correttamente per chiunque non appartenesse al nostro dominio, in realtà non ne valeva la pena.

Per mantenere la tua applicazione mantenibile, renderei la configurazione il più semplice possibile. Alla tua domanda sui database separati, se non ti comprano nulla essendo separati, riduci la complessità e uniscili. Dal momento che sono una intranet, presumo che non verranno mai distribuiti separatamente.