Was ist die beste Strategie, Intranet- und Web-exponierten Website zu verbinden?

Question

Ich habe mich gefragt, ob jemand einen Einblick zu diesem Thema hat.

Ein wenig Hintergrund :

Wir haben Rails wurde unter Verwendung von einem alten dBase und Visual Basic-basierten System zu migrieren unternehmensinternen Intranets zu bauen, die Dinge wie Etikettendruck der Fall ist, invetory Kontrolle, Versand, etc. - im Grunde ein ERP

Das Dilemma

Im Moment brauchen wir eine alte kundenorientierten Website zu ersetzen, die in Java getan wurde, dass würde eine Verbindung zu unserem internen System für unsere Kunden zu verwenden. Wir wollen in die Lage, Informationen wie Inventar, um die Platzierung zu ziehen, Kontoauszüge aus unserem internen System und setzen Sie es, um vor Ort zu Hause ist. Der Grund dafür ist, dass wir nehmen Bestellungen auf der Website, über Fax und Telefon und manchmal haben wir Walk-In. Also manchmal (sehr selten thou) selbst eine kurze Verzögerung bei der Bestandsführung auf unserer alten Java-Website führt uns einen Auftrag im Rückstand setzen, weil wir das gleiche Element zu 2 Kunden innerhalb eines halben Stunde zu verkaufen. Es ist in der Regel innerhalb eines Tages fest, aber wir wollen, dass diese in Zukunft vermeiden.

Die tatsächliche Frage

Hat jemand irgendwelche Vorschläge, wie dies zu tun in einem besseren Art und Weise?

Hier sind drei Möglichkeiten, die ich sehe:

Bauen

a) eine separate Rails-Anwendung auf einem Webserver, die verbinden werden die gleiche DB, die unsere internen App einer Verbindung zu.

• +++ Pluses: Live-Daten - gleiche Sache, dass unsere internen Anwendungen zu sehen, das heißt Aufträge in Echtzeit erstellt werden, Inventar erschöpft ist direkt

• --- Nachteile:. Potenzielles Sicherheitsrisiko dar, Duplizierung von Code - das heißt ich alle Controller, Modelle, Ansichten etc. kopieren muß, die mit dem Befehl umgehen

Bauen

b) eine separate Rails-Anwendung auf einem Web-Server, der auf eine andere DB unserer internen App verbinden.

• +++ Pluses. Weniger Sicherheitsrisiken
• --- Nachteile: Extrabemühung Web DB und interne DB (oder über einen Web-Service wie REST-API), zusätzlichen Code zu synchronisieren Bestandsabbau und Ordnung # Erstellung, Vervielfältigung von Code zu handhaben - also ich brauche alle zu duplizieren die Controller, Modelle, Ansichten, etc., die mit Aufträgen befassen.

c) Expose interne App im Web

• +++ Pluses: alle Probleme von oben eliminiert. Das ist viel "DRY" er-Methode.
• --- Nachteile: Viel mehr Sicherheit Kopfschmerzen. Kompliziertere Login-Systeme - ein für Web & ein für interne Benutzer mittels LDAP
.

So irgendwelche Gedanken? Jeder hatte ähnliches Problem zu lösen? Bitte beachten Sie, dass unser Unternehmen über begrenzte Ressourcen verfügt - nämlich ein Entwickler, der dazu bestimmt ist. So hat dies eine der „richtige“ und „intelligente“ Lösungen sein, nicht Lösungen „Geld / people / Ressourcen auf dieser Wurf“.

Danke.

Answer 1

Ich würde wahrscheinlich getrennte Regler für die öffentliche Website erstellen und Active verwenden, um Daten von Ihnen interner Anwendung zu ziehen. Werfen Sie einen Blick auf

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

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

Bearbeiten - feste Querung und hinzugefügt api Link

Answer 2

Ich würde für eine gehen. Sie sollten in der Lage sein, die Steuerungen zu schaffen, damit sie wiederverwendbar sind.

Interne Benutzer sind so häufig Daten als externer Benutzer duplizieren.

Answer 3

Es ist wahrscheinlich, dass eine öffentliche UI und ein internes, for-the-Personal wird UI müssen, anders sein. Die Daten müssen konsistent sein, damit ich in sichergestellt ziemlich viel Mühe geben würde, dass es genau eine endgültige Datenbank. Also: eine Datenbank zwei UIs

Haben Sie eine „Service“ Schicht, die beide UIs verwenden können. Wenn diese Java würde ich ziemlich sicher sein, die Dienste immer schnell erledigt. Ich frage mich, wie einfach es in Ruby / Rails ist.

Das beste Ergebnis wäre, dass Ihre bestehenden Kunden Java UI angepasst werden kann, die Rails-Service-Layer zu verwenden.

Answer 4

Angenommen, Sie Ihre Programmierer vertrauen nicht aus Versehen an der falschen Stelle aussetzen, die ‚richtige‘ Lösung scheint mir eine einzige Anwendung zu haben, aber zwei verschiedene Arten von Steuerungen und Ansichten, eine für den internen Gebrauch und eine für den öffentlichen -facing. Dies wird Ihnen djna Idee einer Datenbank, zwei UIs.

Wie Sie zwei separate Datenbanken sagen haben wird eine Menge von Doppelarbeit zu beteiligen, sowie das Problem der Replikation.

Es macht keinen Sinn für mich macht zwei völlig getrennte Anwendungen die gleiche Datenbank zu haben, verwendet wird; der Active Teil einer Rails-Anwendung eine Abstraktion der Datenbank in Ruby-Code ist also zwei Abstraktionen für eine einzelne Datenbank mit etwas falsch zu sein scheinen.

Sie können auch haben dann gemeinsam Geschäftsregeln in Ihren Modellen, Code-Duplizierung über die beiden Versionen der Website zu vermeiden.

Wenn Sie nicht vollständig Ihre Programmierer vertrauen, dann Mikes Active Ansatz ist ziemlich gut - es wäre es viel schwieriger, die Dinge durch Zufall zu belichten (obwohl Active viel weniger flexibel ist und reich an Funktionen als Active)

Answer 5

Welche Version von Rails verwenden Sie? Seit der Version 2.3 Rails Engines enthalten ist, ermöglicht dies gemeinsamen Code (Modelle / Ansichten / Controller) in einer Rails-Plugin zu teilen.

Sehen Sie die Railscast für eine kurze Einführung.

Ich benutze es auch. Ich habe für verschiedene Kunden drei Anwendungen entwickelt, aber mit all dem gemeinsamen Code in einem Plugin.