Qual è la strategia migliore per combinare intranet e sito Web esposti?

Question

Mi chiedevo se qualcuno ha qualche informazione su questo tema.

Un po 'di storia :

Stiamo usando Rails per migrare da un vecchio sistema basato su dBase e Visual Basic per costruire intranet aziendale interna che fa le cose come la stampa di etichette, Controllo Invetory, il trasporto, ecc - in pratica un ERP

Il dilemma

In questo momento abbiamo bisogno di sostituire un vecchio sito web rivolti ai clienti che è stato fatto in Java, che avrebbe collegato al nostro sistema interno per i nostri clienti di utilizzare. Vogliamo essere in grado di tirare le informazioni come l'inventario, dell'ordine, estratti conto dal nostro sistema interno ed esporlo al sito dal vivo. La ragione è che noi prendere ordini sul sito web, tramite fax e telefono e qualche volta abbiamo walk-in. Così a volte (molto raramente thou) anche un breve ritardo nella aggiornamento dell'inventario sul nostro sito vecchio Java ci fa mettere un ordine in arretrato, perché vendiamo lo stesso articolo a 2 clienti nel giro di mezz'ora. Di solito è risolto entro un giorno, ma vogliamo evitare questo in futuro.

Domanda reale

Qualcuno ha qualche suggerimento su come ottenere questo risultato in una migliore modo?

Qui ci sono tre opzioni che vedo:

a) Costruire un'applicazione Rails separato su un server web, che si collegherà alla stesso DB che la nostra applicazione interna si collega a.

• +++ Vantaggi: dati in tempo reale - stessa cosa che le nostre applicazioni interne vedono, vale a dire gli ordini vengono creati in tempo reale, l'inventario è esaurito subito

• --- Svantaggi:. Potenziale rischio per la sicurezza, la duplicazione del codice - vale a dire che ho bisogno di duplicare tutti i controller, i modelli, viste, ecc che si occupano di ordini

b) Costruire un'applicazione separata Rails su un server web, che si connetterà a un diverso DB dalla nostra applicazione interna.

• +++ Vantaggi:. L'esposizione di sicurezza Meno
• --- Svantaggi: lo sforzo extra per la sincronizzazione Web DB e DB interna (o utilizzando un servizio web come REST-API), codice aggiuntivo per gestire l'esaurimento delle scorte e ordine di creazione #, la duplicazione del codice - vale a dire che ho bisogno di duplicare tutto i controllori, i modelli, viste, ecc che si occupano di ordini.

c) Esporre applicazione interna al web

• +++ Vantaggi: tutti i problemi dall'alto eliminato. Questo è molto metodo er "DRY".
• --- Svantaggi: Un sacco di sicurezza più mal di testa. Sistemi più complessi d'accesso - uno per il web e una per gli utenti interni che utilizzano LDAP
.

Quindi, ogni pensiero? Chiunque ha avuto problema simile a risolvere? Si prega di tenere presente che la nostra azienda dispone di risorse limitate - vale a dire uno sviluppatore che è dedicato a questo. Quindi, questo deve essere uno di quelli e di soluzioni "giuste" "intelligenti", non "buttare soldi / persone / risorse a questo" soluzioni.

Grazie.

Answer 1

Vorrei probabilmente creare controller separati per il sito pubblico e utilizzare ActiveResource per estrarre i dati da voi applicazione interna. Date un'occhiata a

http://blog.rubybestpractices.com/posts/gregory/rails_modularity_1.html

http://api.rubyonrails.org/classes/ActiveResource/Base.html

Modifica - collegamento fisso e ha aggiunto collegamento api

Answer 2

vorrei andare per una. Si dovrebbe essere in grado di creare i controller in modo che siano riutilizzabili.

Gli utenti interni sono più probabilità di duplicare i dati come utenti esterni.

Answer 3

E 'probabile che un utente pubblica e una interna, per-il-personale, interfaccia utente avrà bisogno di essere diversi. I dati devono essere coerenti quindi vorrei mettere un po 'di sforzi per assicurare che ci sia esattamente un database definitiva. Quindi: un database di due interfacce utente

avere uno strato di "servizio" che entrambi interfacce utente può utilizzare. Se questo è stato Java sarei abbastanza fiducioso di ottenere i servizi di fatto in fretta. Mi chiedo come sia facile in Ruby / Rails.

Il miglior risultato sarebbe che il vostro cliente esistente Java UI può essere adattato per utilizzare il livello di servizio Rails.

Answer 4

Supponendo che si fidi dei tuoi programmatori di non esporre accidentalmente le cose nel posto sbagliato, la soluzione 'giusta' mi sembra di avere una singola applicazione, ma due diverse serie di controllori e vedute, una per uso interno, e uno per il pubblico -facing. Questo vi darà un'idea di un database di djna, due interfacce utente.

Come dici tu avere due database separati sta per coinvolgere un sacco di doppioni, come pure il problema di replica.

Non ha senso per me avere due applicazioni completamente separati utilizzando lo stesso database; la parte ActiveRecord di un'applicazione Rails è un'astrazione del database nel codice Ruby, quindi avere due astrazioni per un singolo database sembra un po 'sbagliato.

Si può anche avere quindi le regole di business comuni nei modelli, al fine di evitare la duplicazione del codice tra le due versioni del sito.

Se non vi fidate completamente i tuoi programmatori, quindi l'approccio ActiveResource di Mike è abbastanza buono - che renderebbe molto più difficile per esporre le cose per caso (anche se ActiveResource è molto meno flessibile e ricco di funzionalità di ActiveRecord)

Answer 5

Quale versione di Rails stai usando? Dal momento che la versione 2.3 di Rails Motori è incluso, questo permette di condividere codice comune (modelli / views / controller) in un plugin Rails.

Vedere la Railscast per una breve introduzione.

Io lo uso troppo. Ho sviluppato tre applicazioni per diversi clienti, ma con tutto il codice condiviso in un plugin.