イントラネットと Web 公開 Web サイトを組み合わせる最善の戦略は何ですか?

Question

誰かがこの問題について何らかの洞察を持っているかどうか疑問に思いました。

ちょっとした背景:

レールを使用して、古いDBaseおよびVisual Basicベースのシステムから移行して、ラベル印刷、invertoryコントロール、出荷などを行う内部会社イントラネットを構築しています - 基本的にERP

ジレンマ

現在、Javaで行われた古い顧客向けのWebサイトを交換する必要があります。在庫、注文、口座明細などの情報を社内システムから取得し、サイトにライブで公開できるようにしたいと考えています。その理由は、注文はウェブサイト、ファックス、電話で受け付けており、場合によってはウォークインで注文を受け付けているためです。そのため、古い Java サイトの在庫更新が少し遅れただけで、注文がバックオーダーになることがあります (30 分以内に 2 人の顧客に同じ商品を販売しているため)。通常は 1 日以内に修正されますが、今後はこれを避けたいと考えています。

実際の質問

これをより良い方法で達成する方法について何か提案がありますか？

私が見たのは次の 3 つのオプションです。

a) Web サーバー上に別の Rails アプリを構築します。 同じ 内部アプリが接続する DB。

• +++ プラス: ライブデータ - 内部アプリが見るものと同じものです。注文はリアルタイムで作成され、在庫はすぐになくなります

• --- マイナス点:潜在的なセキュリティリスク、コードの重複 - 例:すべてのコントローラー、モデル、ビューなどを複製する必要があります。注文を扱うもの。

b) Web サーバー上に別の Rails アプリを構築します。 違った 社内アプリからの DB。

• +++ プラス:セキュリティ上の危険が軽減されます。
• --- マイナス点: Web DB と内部 DB を同期するための余分な労力 (または REST-API などの Web サービスの使用)、在庫の枯渇と注文番号の作成を処理するための追加のコード、コードの重複 - 例:すべてのコントローラー、モデル、ビューなどを複製する必要があります。注文を扱うもの。

c) 内部アプリを Web に公開する

• +++ プラス:上記の問題はすべて解消されました。これは、より「DRY」な方法です。
• --- マイナス点:セキュリティの問題がさらに増えました。より複雑なログイン システム - 1 つは Web 用、もう 1 つは LDAP を使用する内部ユーザー用です。

それで何か考えはありますか？同様の問題を解決したい人はいますか?当社のリソースは限られており、これに専念する開発者は 1 名であることに注意してください。したがって、これは「お金、人材、リソースをこれに投入する」ソリューションではなく、「正しく」「賢い」ソリューションの 1 つである必要があります。

ありがとう。

Answer 1

おそらく、パブリック サイト用に別のコントローラーを作成し、ActiveResource を使用して内部アプリケーションからデータを取得するでしょう。を見てみましょう

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

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

編集 - リンクを修正し、API リンクを追加しました

Answer 2

私なら を選びます。再利用できるようにコントローラーを作成できる必要があります。

内部ユーザーは外部ユーザーと同じくらいデータを複製する可能性があります。

Answer 3

おそらく、パブリック UI と内部のスタッフ用 UI は異なる必要があるでしょう。データには一貫性が必要なので、決定的なデータベースが 1 つだけ存在するようにするためにかなりの労力を費やします。それで：1 つのデータベースに 2 つの UI?

両方の UI が使用できる「サービス」レイヤーを用意します。これが Java だったら、サービスをすぐに完了できる自信があるでしょう。Ruby/Rails だとどれだけ簡単なんだろう。

最良の結果は、既存の顧客 Java UI を Rails サービス層の使用に適応できることです。

Answer 4

プログラマーが誤って間違った場所に公開しないと信頼していると仮定すると、「正しい」ソリューションは、アプリケーションは 1 つですが、コントローラーとビューの 2 つの異なるセット (1 つは内部使用用、もう 1 つは公開用) を持つように思えます。これにより、1 つのデータベース、2 つの UI という djna のアイデアが得られます。

あなたが言うように、2つの別々のデータベースを持つことは、レプリケーションの問題だけでなく、多くの重複を伴​​うことになります。

同じデータベースを使用する 2 つのまったく別個のアプリがあることは、私にとっては意味がありません。Rails アプリの ActiveRecord 部分は Ruby コードのデータベースの抽象化であるため、1 つのデータベースに 2 つの抽象化があるのは少し間違っているように思えます。

また、サイトの 2 つのバージョン間でのコードの重複を避けるために、モデルに共通のビジネス ルールを含めることもできます。

プログラマーを完全に信頼していない場合は、Mike の ActiveResource アプローチは非常に優れています。これにより、偶然に物事を公開することがはるかに困難になります (ただし、ActiveResource は、ActiveRecord よりも柔軟性と機能がはるかに劣ります)

Answer 5

Rails のどのバージョンを使用していますか?バージョン 2.3 Rails Engine が含まれているため、Rails プラグインで共通のコード (モデル/ビュー/コントローラー) を共有できます。

を参照してください。 レールキャスト 簡単な紹介のために。

私も使っています。私はさまざまなクライアント向けに 3 つのアプリケーションを開発しましたが、すべての共有コードはプラグイン内にありました。