2013-04-10 4 views
0

Я работаю над новым приложением (приложение 2), у меня уже есть существующее приложение (приложение 1) с достойной базой пользователей.Обмен данными между двумя веб-приложениями

Приложение 2 предназначено для одной и той же пользовательской базы, пользователь может использовать любое из приложений или их обоих, как я могу обмениваться пользовательскими данными (несколькими объектами) через приложения?

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

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

опции 3 - обрабатывать хранилище данных App 1 как центральное хранилище данных и выставлять его как API. Приложение 2 может использовать это для чтения и записи данных. У меня все еще есть несколько вопросов для этого решения.

  • Приложение 2 теперь зависит от приложения 1, что означает, что проблема с App 1 влияет на приложение 2. Я могу решить эту проблему путем кэширования данных в приложении 2. Это приводит к другим проблемам.
  • Данные, измененные в Приложении 1, сразу не отражаются в приложении 2, что является одним из требований. Я могу решить эту проблему с помощью pub/sub model между App 1 и App 2.
  • Приложение 2 всегда записывает данные в хранилище данных App 1 с использованием API, и я могу вернуть данные обратно в приложение 2, но затем оно несовместимо, а в конечном итоге оно последовательное.
  • Приложение 2 записывает данные в собственное хранилище данных, а затем асинхронно переносится в приложение 1. Это приводит к проблемам с конфликтом данных.

Как я могу справиться с этой проблемой, не представляя огромной сложности в обоих приложениях.

ответ

1

Вот мои два цента.

Самый простой подход заключается в том, чтобы вы могли разделить одну и ту же базу данных, и поскольку вы указали, что база данных может быть разделена, это означает, что правила домена из App1 по-прежнему применяются к App2, и даже если есть некоторые различия, это лучше написать эти изменения, чем написать все это.

Теперь у вас есть большая проблема ИМО, потому что, если я правильно ее понял, у вас нет надлежащего уровня обслуживания, потому что если бы вы это сделали, вы могли бы внести любые изменения в DAL, не затрагивая существующие 1 .

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

  • Какие рамки веб-приложения вы используете т.д .: ASP.Net MVC
  • У вас есть сервис/API Layer и то, что о слоях домена и DAL?

UPDATE

Так что ваши существующие приложения построен в PHP, что если извлечь REST API из приложения 1 и поместить его в совершенно новое решение PHP (сайт), которые могут быть разделены между приложение 1 и приложение 2 в качестве сервисного API? Я считаю, что это было бы самым простым способом для вас.

+0

1. Оба приложения написаны на php , 2. У меня есть неплохой API для приложения 1. Меня беспокоит производительность приложения 2, если я использую его непосредственно в приложении 2. – abhinavlal

+0

Вы даже не должны этого делать, я имею в виду, что App 2 использует Api 1. Можете ли вы извлечь API REST из приложения 1? – Marco

0

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

Это не должно быть большой удар. вы можете начать с добавления правильного API поверх данных пользователей в приложении 1. и сделать app2 использовать это. Затем вы можете добавить слой абстракции в app1, который говорит с новым API и будет выглядеть как внутренние API-интерфейсы App1 для APP1, и только затем переместить данные в новую базу данных, которая станет новой услугой.

Смежные вопросы