n-уровневый дизайн с обработчиком транзакций веб-сайта и бэкэнд

Question

У нас есть веб-сайт, на котором транзакции вводятся и обрабатываются потоком. Мы будем следовать стандартным BLL (Business Logic Layer), DTO (объект передачи данных), DAL (уровень доступа к данным) и т. Д. Для многоуровневого приложения. У нас есть необходимость разделить все, потому что некоторые транзакции будут пересекать несколько приложений с различной бизнес-логикой.

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

Теперь вопрос с N-Tier предлагает новый BLL для каждого приложения. С макетом приложения выше можно утверждать, что серверный процессор и веб-сайт - это одно приложение, действующее в унисон, или два приложения с различной бизнес-логикой. Каким будет идеальный способ справиться с этим? Действовать ли она как одна система или две?

Answer 1

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

Логика домена - это «традиционная» бизнес-логика, как все должно действовать, что им требуется (валидация) и т. Д. Логика приложения - это все, что характерно для данной презентации вашего домена, IE, когда пользователь нажимает эту кнопку отправки в своем веб-приложении, то они направляются на эту веб-страницу здесь (обратите внимание, что у этого ничего нет, чтобы работать с приложением WinForms или фоновым процессором). Логика приложения должна работать в вашем приложении.Логика домена должна жить в вашем BLL и ниже и быть повторно использована в разных приложениях, которые могут использовать вашу общую «бизнес-логику».

Вид общего ответа, но я надеюсь, что это поможет.

Answer 2

«Идеальный» способ сделать это зависит от проекта и различных требований системы.

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

Answer 3

Если вы хорошо отделите свои проблемы, я думаю, что вы сможете просматривать их как одно приложение с одним уровнем бизнес-логики, нет смысла писать один и тот же код дважды. Этот трюк будет заставлять разделять проблемы между частями пользовательского интерфейса веб-сайта и бизнес-логикой в ​​вашей библиотеке BLL.

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

Я бы сохранил общую библиотеку бизнес-логики, запрограммированную на интерфейсы и полностью отделенную от ваших других проблем.

Answer 4

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

Большинство из нас не тратит много времени на написание приложений, которые исследуют внешние границы аппаратных и программных возможностей.