Backoffice и Frontoffice для разделения проектов

Question

Я строю проект, используя mvc framework.

Я нахожусь в точке, где мне нужно решить, следует ли мне отделить фронтенд и бэк-офис от двух приложений mvc

Это должно сделать мое решение аккуратным и хорошо структурированным. Но в то же время я не хочу увеличивать техническое обслуживание в долгосрочной перспективе. Можете ли вы поделиться со мной своим опытом в долгосрочной перспективе, когда приложение становится достаточно большим, если лучше иметь два отдельных проекта или просто иметь папку Backoffice под основным веб-проектом.

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

Спасибо

Answer 1

Один из способов подумать об этом - спросить «Отличаются ли основные действия и желания пользователей». Затем спросите: «Каков масштаб бэк-офиса сайта». Чем больше, тем больше вероятность, что я разделю это. Если бы это была всего лишь несколько страниц администратора или пара отчетов, я бы жил с этим в первоначальном проекте. Кроме того, "должны ли фронт-офисы и бэк-офисы масштабироваться с разной скоростью?" 1 миллион обращений / час против 20 исполнителей, чтобы сделать цифры из ниоткуда. И, в-третьих, «клиенты фронт-офиса и бэк-офиса живут в разных доменах безопасности». Возможность развертывания кода бэк-офиса за брандмауэром сделает его безопаснее.

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

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

Answer 2

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

a) Вы можете перейти к материалам бэк-офиса, пока некоторые детали интерфейса еще обсуждаются. IE - вы не заблокированы маркетингом, который всецело интересуется тем, какой шаблон и цветовую схему использовать.

б) Вы можете выбирать различные технологии в зависимости от приложения. Например, ваш бэк-офис может использовать традиционные веб-формы ASP.NET, потому что вы не заботитесь о SEO и другом поведении в Интернете, а также можете гарантировать, с какими браузерами и пропускной способностью вам придется иметь дело.

Сверхурочные, на самом деле не так уж много дополнительной работы ИМХО. И большинство из этих проблем довольно разрешимы. Например, проблема с изображениями может быть решена путем сохранения изображений в базе данных или создания общего хранилища файлов, на которое могут ссылаться оба приложения.