Quelle est la meilleure stratégie pour combiner intranets et site Web exposé?

Question

Je me demandais si quelqu'un a une idée sur cette question.

Un peu d'histoire :

Nous avons utilisé Rails pour migrer d'un ancien système basé dBase et Visual Basic pour construire la société interne IntrAnet qui fait des choses comme l'impression d'étiquettes, contrôle invetory, expédition, etc. - essentiellement un ERP

Le Dilemme

En ce moment, nous avons besoin de remplacer un ancien site Web destiné au client qui a été fait en Java, que se connecter à notre système interne pour nos clients à utiliser. Nous voulons être en mesure de tirer des informations telles que l'inventaire, le placement des commandes, les relevés de compte de notre système interne et l'exposer sur le site en direct. La raison en est que nous prenons les commandes sur le site, par fax et téléphone, et parfois nous avons walk-ins. Alors parfois (très rarement tu), même un court délai de mise à jour de l'inventaire sur notre ancien site Java nous amène à mettre un ordre en rupture de stock, parce que nous vendons le même article 2 clients dans une demi-heure. Il est généralement fixé dans un jour, mais nous voulons éviter cela à l'avenir.

Question réelle

Quelqu'un at-il des suggestions sur la façon d'y arriver dans une meilleure façon?

Voici trois options que je vois:

a) Construire une application Rails séparés sur un serveur web, qui se connecte à même DB que notre application interne se connecte.

• +++: Pluses données en direct - même chose que nos applications internes voir, à savoir les commandes sont créées en temps réel, épuisement des stocks tout de suite

• --- Minuses:. Risque potentiel, la duplication code - à savoir que je dois dupliquer tous les contrôleurs, les modèles, vues, etc. qui traitent des commandes

b) Construire une application Rails séparés sur un serveur web, qui se connecte à un autre DB à partir de notre application interne.

• +++: Pluses. Moins d'exposition de sécurité
• --- Minuses: effort supplémentaire pour la synchronisation web DB et DB interne (ou en utilisant un service Web comme REST-API), le code supplémentaire pour gérer l'épuisement des stocks et pour la création de #, la duplication code - à savoir que je dois reproduire tous les contrôleurs, modèles, vues, etc. qui traitent des commandes.

c) exposer l'application interne à l'âme

• +++: tous les Pluses problèmes ci-dessus de éliminés. Cela est beaucoup méthode er "SEC".
• --- Minuses: Beaucoup plus de maux de tête de sécurité. systèmes de connexion plus complexes - un pour le Web et un pour les utilisateurs internes utilisant LDAP
.

Alors toute pensée? Tout le monde avait le même problème à résoudre? S'il vous plaît garder à l'esprit que notre société dispose de ressources limitées - à savoir un développeur qui est dédié à ce sujet. Donc, ce doit être l'un de ces « bons » et des solutions « intelligentes », pas « jeter de l'argent / personnes / ressources à cette » solutions.

Merci.

Answer 1

Je serais probablement créer des contrôleurs séparés pour le site public et utiliser ActiveResource pour extraire des données de votre application interne. Jetez un oeil à

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

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

Modifier - lien fixe et ajouté lien api

Answer 2

Je pencherais pour un. Vous devriez être en mesure de créer les contrôleurs afin qu'ils soient réutilisables.

Les utilisateurs internes sont aussi susceptibles de dupliquer des données que les utilisateurs externes.

Answer 3

Il est probable qu'une interface publique et une interne, pour-personnel, l'interface utilisateur aura besoin d'être différent. Les données doivent être cohérentes et je mettrais un peu d'efforts pour assurer qu'il ya exactement une base de données définitive. Donc: une base de données deux interfaces

Avoir une couche « service » que les deux UIs peut utiliser. Si tel était Java je serais assez confiant d'obtenir les services rendus rapidement. Je me demande comment il est facile dans Ruby / Rails.

Le meilleur résultat serait que votre interface utilisateur Java Client existant peut être adapté pour utiliser la couche de service Rails.

Answer 4

En supposant que vous faites confiance à vos programmeurs de ne pas exposer accidentellement les choses au mauvais endroit, la solution « droit » me semble avoir une seule application, mais deux ensembles différents de contrôleurs et points de vue, l'un pour un usage interne, et un pour le public -orienté vers. Cela vous donnera l'idée de djna d'une base de données, deux interfaces.

Comme vous le dites avoir deux bases de données distinctes va impliquer beaucoup de doubles emplois, ainsi que le problème de la réplication.

Il n'a pas de sens pour moi d'avoir deux applications totalement distinctes en utilisant la même base de données; la partie ActiveRecord d'une application Rails est une abstraction de la base de données dans le code Ruby, donc ayant deux abstractions pour une base de données unique semble un peu de mal.

Vous pouvez aussi avoir alors des règles commerciales communes dans vos modèles, afin d'éviter la duplication de code entre les deux versions du site.

Si vous ne vous fiez pas complètement vos programmeurs, alors l'approche ActiveResource de Mike est très bon - il serait beaucoup plus difficile d'exposer les choses par accident (même si ActiveResource est beaucoup moins flexible et riche en fonctionnalités que ActiveRecord)

Answer 5

Quelle version de Rails utilisez-vous? Depuis la version 2.3 Rails moteurs est inclus, ce qui permet de partager le code commun (modèles / vues / contrôleurs) dans un plugin Rails.

Voir la Railscast pour une courte introduction.

Je l'utilise aussi. J'ai développé trois applications pour différents clients, mais avec tout le code partagé dans un plug-in.