Какова лучшая стратегия для объединения IntrAnet и веб-сайта?

Question

Мне было интересно, есть ли у кого-нибудь понимание этого вопроса.

Небольшой фон :

Мы использовали Rails для перехода от старой системы на базе dBase и Visual Basic создать внутреннюю компанию IntrAnet, которая занимается печатью этикеток, Инвентарный контроль, доставка и т. д. - в основном ERP

Дилемма

Сейчас нам нужно заменить старый веб-сайт, ориентированный на клиентов, который был сделан на Java, который будет подключаться к нашей внутренней системе для использования нашими клиентами. Мы хотим иметь возможность извлекать такую ​​информацию, как инвентарь, размещение заказов, выписки со счетов из нашей внутренней системы, и размещать ее на сайте в режиме реального времени. Причина в том, что мы принимаем заказы на веб-сайте, по факсу и телефону, а иногда и у нас есть проходы. Так что иногда (очень редко) даже небольшая задержка в обновлении инвентаря на нашем старом Java-сайте заставляет нас размещать заказы, поскольку мы продаем один и тот же товар двум клиентам в течение получаса. Обычно это исправляется в течение одного дня, но мы хотим избежать этого в будущем.

Актуальный вопрос

Кто-нибудь есть какие-либо предложения о том, как сделать это в лучшую сторону способ

Вот три варианта, которые я вижу:

a) Создайте отдельное приложение Rails на веб-сервере, которое будет подключаться к той же БД, к которой подключается наше внутреннее приложение.

• +++ Плюсы: оперативные данные - то же, что видят наши внутренние приложения, то есть заказы создаются в режиме реального времени, запасы расходуются сразу

• --- Минусы: потенциальная угроза безопасности, дублирование кода - т.е. мне нужно продублировать все контроллеры, модели, представления и т. Д., Имеющие дело с заказами.

b) Создайте отдельное приложение Rails на веб-сервере, которое будет подключаться к другой БД из нашего внутреннего приложения.

• +++ Достоинства: Меньше риска для безопасности.
• --- Минусы: дополнительные усилия для синхронизации веб-базы данных и внутренней базы данных (или использования веб-службы, такой как REST-API), дополнительный код для обработки исчерпания запасов и создания # заказа, дублирование кода - т.е. мне нужно дублировать все контроллеры, модели, представления и т. д., связанные с заказами.

в) Выставить внутреннее приложение в Интернете

• +++ Достоинства: все проблемы сверху устранены. Это гораздо более "СУХОЙ" метод.
• --- Минусы: намного больше проблем с безопасностью. Более сложные системы входа в систему - одна для веб-сайтов и одна для внутренних пользователей, использующая LDAP.

Так есть мысли? У кого-нибудь была похожая проблема, которую нужно решить? Помните, что у нашей компании ограниченные ресурсы, а именно один разработчик, который занимается этим. Так что это должно быть одно из тех «правильных» и «умных» решений, а не «бросать деньги / людей / ресурсы на это».

Спасибо.

Answer 1

Какую версию Rails вы используете? Поскольку версия 2.3 Rails Engines включена, это позволяет совместно использовать общий код (модели / представления / контроллеры) в плагине Rails.

См. Railscast для краткого введения.

Я тоже этим пользуюсь. Я разработал три приложения для разных клиентов, но со всем общим кодом в плагине.

Answer 2

Предполагая, что вы доверяете своим программистам не случайно выставлять вещи в неправильном месте, мне кажется, что «правильное» решение состоит из одного приложения, но двух разных наборов контроллеров и представлений, одного для внутреннего использования и одного для публичного -facing. Это даст вам представление djna об одной базе данных, двух пользовательских интерфейсах.

Как вы говорите, наличие двух отдельных баз данных потребует большого количества дублирования, а также проблемы репликации.

Мне не имеет смысла иметь два совершенно разных приложения, использующих одну и ту же базу данных; часть ActiveRecord приложения Rails представляет собой абстракцию базы данных в коде Ruby, поэтому наличие двух абстракций для одной базы данных кажется немного неправильным.

Затем вы также можете использовать общие бизнес-правила в своих моделях, чтобы избежать дублирования кода в двух версиях сайта.

Если вы не полностью доверяете своим программистам, тогда подход Майка к ActiveResource довольно хорош - это усложнит случайное раскрытие информации (хотя ActiveResource намного менее гибок и многофункциональн, чем ActiveRecord)

Answer 3

Вероятно, что общедоступный пользовательский интерфейс и внутренний пользовательский интерфейс должны отличаться. Данные должны быть непротиворечивыми, поэтому я бы приложил немало усилий, чтобы убедиться, что существует только одна, точная база данных. Итак: одна база данных, два интерфейса?

Имеют слой "обслуживания", который могут использовать оба интерфейса пользователя. Если бы это была Java, я бы был уверен в том, что услуги будут выполнены быстро. Интересно, как это просто в Ruby / Rails.

Наилучшим результатом будет то, что ваш существующий пользовательский пользовательский интерфейс Java клиента может быть адаптирован для использования уровня обслуживания Rails.

Answer 4

Я бы, вероятно, создал отдельные контроллеры для публичного сайта и использовал бы ActiveResource для извлечения данных из вашего внутреннего приложения. Взгляните на

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

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

Редактировать - исправлена ​​ссылка и добавлена ​​ссылка на API

Answer 5

Я бы пошел за. Вы должны иметь возможность создавать контроллеры, чтобы их можно было повторно использовать.

Внутренние пользователи могут дублировать данные так же, как и внешние пользователи.