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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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