Лучший способ поделиться кодом между несколькими приложениями MVC и развернуть разные версии

Question

Лучший способ поделиться кодом между несколькими приложениями MVC и развернуть разные версии

1

В настоящее время мы имеем единую базу данных с пользователями, клиентами, продуктами и заказами, логически разделенными схемами. Затем у нас есть несколько приложений MVC.net, которые обращаются к базе данных через свои собственные BLL. Каждое из этих приложений имеет свои собственные функции и разделяет некоторые аспекты с некоторыми/всеми другими приложениями.

В настоящее время некоторые коды дублируются в этих BLL, и это немного беспорядок для поддержания. Тем не менее, это позволяет нам быстро разрабатывать функции и развертывать каждое приложение независимо (при условии, что здесь работает основная база данных).

Мы начали разрабатывать единый уровень доступа, должным образом отделенный, который находится над базой данных и используется всеми нашими приложениями MVC.net. Логически это имеет смысл, поскольку теперь мы можем совместно использовать код между нашими приложениями. Например, приложение A может получить запись клиента так же, как приложение B. Проблема возникает, когда мы хотим развернуть приложение, мы не сможем развернуть одно приложение, нам нужно будет развернуть их все.

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

gilbert 16 июнь 2014, в 22:49

Источник

0

Что такое BLL, вы неправильно набрали DLL (сборка)?
Erik Philips 16 июнь 2014, в 20:30
0

@ErikPhilips BLL - это сокращение от уровня бизнес-логики
Andreas 16 июнь 2014, в 20:31
0

Вы рассматриваете создание веб-API?
Ignacio Laborde 16 июнь 2014, в 20:47

Показать ещё 1 комментарий

Теги:

c#

architecture

asp.net-mvc

1 ответ

Ещё вопросы

Что такое BLL, вы неправильно набрали DLL (сборка)?
@ErikPhilips BLL - это сокращение от уровня бизнес-логики
Вы рассматриваете создание веб-API?

Andreas · Answer 1 · 2014-06-16T18-49-00.000Z

Общим решением является разукрупнение сервисов (на основе произвольного уровня связи REST, WCF, шины сообщений, вашего выбора при управлении версиями) и развертывание этих служб в вашей инфраструктуре как автономные службы.

Теперь вы можете развивать, масштабировать и развертывать свои услуги независимо от потребителей. Вместо развертывания всех приложений вам нужно только развернуть измененные службы (бок о бок со старыми) и новое приложение.

Это добавляет довольно много сложностей в отношении управления версиями, управления конфигурацией, тестирования интеграции, небольших коммуникационных издержек и т.д. Таким образом, вы должны сбалансировать плюсы и минусы. В сети есть множество статей о том, как построить такую архитектуру.