结合 IntrAnet 和 Web 公开网站的最佳策略是什么？
我想知道是否有人对这个问题有一些见解。
一点背景：
我们一直在使用 Rails 从旧的 dBase 和基于 Visual Basic 的系统迁移 建立内部公司 IntraAnet 来进行标签打印等工作， 库存控制、运输等 - 基本上是一个 ERP
困境
现在我们需要替换一个用 Java 完成的旧的面向客户的网站， 将连接到我们的内部系统供我们的客户使用。我们希望能够从我们的内部系统中提取库存、下单、账户报表等信息，并将其实时公开到网站上。原因是我们在网站上通过传真和传真接受订单。电话，有时我们会有上门服务。因此，有时（很少见），即使我们的旧 Java 网站上的库存更新出现短暂延迟，也会导致我们延期交货订单，因为我们在半小时内向 2 个客户出售相同的商品。它通常会在一天内修复，但我们希望将来避免这种情况。
实际问题
有没有人对如何更好地实现这一点有任何建议 方式？
以下是我看到的三个选项：
a) 在 Web 服务器上构建一个单独的 Rails 应用程序，该应用程序将连接到我们的内部应用程序所连接的同一数据库。
+++ 优点：实时数据 - 与我们的内部应用程序看到的内容相同，即实时创建订单，库存立即耗尽
--- 缺点：潜在的安全风险、代码重复 - 即我需要复制处理订单的所有控制器、模型、视图等.
b) 在 Web 服务器上构建一个单独的 Rails 应用程序，它将连接到与我们的内部应用程序不同的数据库。
- +++ 优点：安全风险较小。
- --- 缺点：同步 Web 数据库和内部数据库（或使用 REST-API 等 Web 服务）需要额外的工作，需要额外的代码来处理库存消耗和订单 # 创建、代码重复 - 即我需要复制所有控制器，处理订单的模型、视图等。
c) 将内部应用程序暴露给网络
- +++ 优点：消除了上述所有问题。这是一种非常“干燥”的方法。
- --- 缺点：更多的安全问题。更复杂的登录系统 - 一个用于网络和网络的登录系统一种适用于使用 LDAP 的内部用户。
那么有什么想法吗？有人有类似的问题需要解决吗？请记住，我们公司的资源有限 - 即一名致力于此的开发人员。因此，这必须是“正确”和“聪明”的解决方案之一，而不是“为此投入金钱/人员/资源”的解决方案。
谢谢。
I was wondering if somebody has some insight on this issue.
A little background:
We've been using Rails to migrate from an old dBase and Visual Basic based system
to build internal company IntrAnet that does things like label printing,
invetory control, shipping, etc - basically an ERP
The Dilemma
Right now we need to replace an old customer-facing website that was done in Java, that
would connect to our internal system for our clients to use. We want to be able to pull information like inventory, order placement, account statements from our internal system and expose it to site live. The reason is that we take orders on the website, through fax & phone and sometimes we have walk-ins. So sometimes (very rarely thou) even a short delay in inventory update on our old Java site causes us to put an order on backorder, because we sell the same item to 2 customers within half an hour. It's usually fixed within one day but we want to avoid this in the future.
Actual Question
Does anyone have any suggestion on how to accomplish this in a better
way?
Here are three options that I see:
a) Build a separate Rails app on a web server, that will connect to the same DB that our internal app connects to.
+++ Pluses:Live data - same thing that our internal apps see, i.e. orders are created in real time, inventory is depleted right away
--- Minuses: Potential security risk, duplication of code - i.e. I need to duplicate all the controllers, models, views, etc. that deal with orders.
b) Build a separate Rails app on a web server, that will connect to a different DB from our internal app.
- +++ Pluses: Less security exposure.
- --- Minuses:Extra effort to sync web DB and internal DB (or using a web service like REST-API), extra code to handle inventory depletion and order # creation, duplication of code - i.e. I need to duplicate all the controllers, models, views, etc. that deal with orders.
c) Expose internal app to the web
- +++ Pluses: all the problems from above eliminated. This is much "DRY"er method.
- --- Minuses: A lot more security headaches. More complicated login systems - one for web & one for internal users using LDAP.
So any thoughts? Anyone had similar problem to solve? Please keep in mind that our company has limited resources - namely one developer that is dedicated to this. So this has to be one of those "right" and "smart" solutions, not "throw money/people/resources at this" solutions.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我可能会为公共站点创建单独的控制器，并使用 ActiveResource 从内部应用程序中提取数据。查看
http://blog.rubybestpractices.com/posts/gregory/rails_modularity_1。 html
http://api.rubyonrails.org/classes/ActiveResource/Base .html
编辑 - 修复链接并添加 api 链接
I would probably create separate controllers for the public site and use ActiveResource to pull data from you internal application. Take a look at
http://blog.rubybestpractices.com/posts/gregory/rails_modularity_1.html
http://api.rubyonrails.org/classes/ActiveResource/Base.html
Edit - fixed link and added api link
我会去的。您应该能够创建控制器，以便它们可以重复使用。
内部用户与外部用户一样有可能复制数据。
I would go for a. You should be able to create the controllers so that they are re-usable.
Internal users are as likely to duplicate data as external users.
公共用户界面和内部、为员工提供的用户界面可能需要有所不同。数据需要一致，因此我会付出相当大的努力来确保有一个明确的数据库。那么：一个数据库两个 UI？
有一个两个 UI 都可以使用的“服务”层。如果这是 Java，我将非常有信心快速完成服务。我想知道在 Ruby/Rails 中这有多容易。
最好的结果是您现有的客户 Java UI 可以适应使用 Rails 服务层。
It's likely that a public UI and an internal, for-the-staff, UI will need to be different. The data needs to be consistent so I would put quite a bit of effort into ensuring that there is exactly one, definitive database. So: one database two UIs?
Have a "service" layer that both UIs can use. If this was Java I would be pretty confident of getting the services done quickly. I wonder how easy it is in Ruby/Rails.
The best outcome would be that your existing Customer Java UI can be adapted to use the Rails service layer.
假设您相信程序员不会意外地将内容暴露在错误的位置，那么在我看来，“正确”的解决方案应该有一个应用程序，但有两组不同的控制器和视图，一组用于内部使用，一组用于面向公众。这将为您提供 djna 的一个数据库、两个 UI 的想法。
正如您所说，拥有两个独立的数据库将涉及大量重复以及复制问题。
对我来说，让两个完全独立的应用程序使用同一个数据库是没有意义的。 Rails 应用程序的 ActiveRecord 部分是 Ruby 代码中数据库的抽象，因此单个数据库有两个抽象似乎有点错误。
然后，您还可以在模型中使用通用的业务规则，以避免站点两个版本之间的代码重复。
如果您不完全信任您的程序员，那么 Mike 的 ActiveResource 方法非常好 - 它将使意外暴露事物变得更加困难（尽管 ActiveResource 的灵活性和功能比 ActiveRecord 少得多）
Assuming you trust your programmers to not accidentally expose things in the wrong place, the 'right' solution seems to me to have a single application, but two different sets of controllers and views, one for internal use, and one for public-facing. This will give you djna's idea of one database, two UIs.
As you say having two separate databases is going to involve a lot of duplication, as well as the problem of replication.
It doesn't make sense to me to have two totally separate apps using the same database; the ActiveRecord part of a Rails app is an abstraction of the database in Ruby code, therefore having two abstractions for a single database seems a bit wrong.
You can also then have common business rules in your models, to avoid code duplication across the two versions of the site.
If you don't completely trust your programmers, then Mike's ActiveResource approach is pretty good - it would make it a lot harder to expose things by accident (although ActiveResource is a lot less flexible and feature rich than ActiveRecord)
您使用什么版本的 Rails？由于包含了 2.3 版本的 Rails Engines，因此允许在 Rails 插件中共享通用代码（模型/视图/控制器）。
请参阅 Railscast 了解简短介绍。
我也用它。我为不同的客户开发了三个应用程序，但所有共享代码都在一个插件中。
What version of Rails are you using? Since version 2.3 Rails Engines is included, this allows to share common code (models/views/controllers) in a Rails plugin.
See the Railscast for a short introduction.
I use it too. I have developed three applications for different clients, but with all the shared code in a plugin.