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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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