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

Question

Je me demandais si quelqu'un avait un aperçu de ce problème.

Un peu d'histoire:

Nous avons utilisé Rails pour migrer d'un ancien dBase et système basé sur 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 connecterait à notre système interne pour nos clients à utiliser. Nous voulons être en mesure de tirer des informations comme l'inventaire, le placement des commandes, les relevés de compte de notre système interne et de l'exposer sur le site en direct. La raison en est que nous prenons des commandes sur le site Web, par fax & téléphone et parfois nous avons des walk-ins. Donc parfois (très rarement), même un court délai dans la mise à jour de l'inventaire sur notre ancien site Java nous oblige à passer une commande en rupture de stock, car nous vendons le même article à 2 clients en une demi-heure. Il est généralement fixé en un jour, mais nous voulons éviter cela à l'avenir.

Question actuelle

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ée sur un serveur web, qui se connecte à la 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, l'inventaire est épuisé tout de suite

• --- Inconvénients: risque de sécurité potentiel, duplication de code - c'est-à-dire que j'ai besoin de dupliquer tous les contrôleurs, 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 de notre application interne.

• +++ Plus: Moins d'exposition de sécurité.
• --- Moins: Effort supplémentaire pour synchroniser la base de données Web et la base de données interne (ou utiliser un service Web comme REST-API), code supplémentaire pour gérer l'épuisement des stocks et la création du numéro de commande les contrôleurs, modèles, vues, etc. qui traitent des commandes.

c) Expose application interne au web

• +++: tous les points positifs problèmes de dessus éliminés. C'est beaucoup "DRY" er méthode.
• --- Les moins: beaucoup plus de maux de tête de sécurité.Systèmes de connexion plus compliqués - un pour le web & un pour les utilisateurs internes utilisant LDAP.

Alors des pensées? Quelqu'un a eu le même problème à résoudre? S'il vous plaît gardez à l'esprit que notre société a des ressources limitées - à savoir un développeur qui est dédié à cela. Il faut donc que ce soit l'une de ces solutions «justes» et «intelligentes», et non pas «jeter de l'argent/des personnes/des ressources à ces solutions».

Merci.

Answer 1

Je créerais probablement des contrôleurs distincts pour le site public et utiliserais 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

Edition - lien fixe et ajouté lien api

Answer 2

Je voudrais aller a. Vous devriez être capable de créer les contrôleurs afin qu'ils soient réutilisables.

Les utilisateurs internes sont susceptibles de dupliquer des données en tant qu'utilisateurs externes.

Answer 3

Il est probable qu'une interface utilisateur publique et une interface utilisateur interne, pour le personnel, doivent être différentes. Les données doivent être cohérentes, donc je mettrais un peu d'effort pour faire en sorte qu'il y ait exactement une base de données définitive. Donc: une base de données deux interfaces utilisateur? Avoir un "service" couche que les deux interfaces utilisateur peuvent utiliser. Si c'était Java, je serais assez confiant d'obtenir les services rapidement. Je me demande comment c'est facile dans Ruby/Rails. Le meilleur résultat serait que votre interface Java Client existante puisse être adaptée 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 » Il me semble avoir une seule application, mais deux ensembles différents de contrôleurs et de vues, un pour usage interne et un pour public. Cela vous donnera l'idée de djna d'une base de données, deux interfaces utilisateur. Comme vous le dites, avoir deux bases de données distinctes impliquera beaucoup de duplication, ainsi que le problème de la réplication.

Cela ne me semble pas logique d'avoir deux applications totalement séparées utilisant la même base de données; la partie ActiveRecord d'une application Rails est une abstraction de la base de données en code Ruby, donc avoir deux abstractions pour une seule base de données semble un peu faux.

Vous pouvez également avoir des règles métier 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 Engines est inclus, cela permet de partager du code commun (models/views/controllers) dans un plugin Rails.

Voir le Railscast pour une brève introduction.

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