Создание корпоративного приложения без сервисного уровня

Question

Существует так много учебных пособий, которые учат нас использовать, например, некоторые ORM напрямую с базой данных, но в реальной жизни я не могу вспомнить большой проект, который работал напрямую с базой данных, а не со службами, поэтому объем этих учебников кажется странным для меня.
Приложения с прямым подключением имеют реальные преимущества в скорости передачи данных между базой данных и приложением, и они не имеют ограничений в функциональности, которые появляются из-за уровней обслуживания (например, давайте возьмем инфраструктуру Entity и службы данных WCF (которая использует ту же модель данных объекта) )). С другой стороны, сервисное решение является более безопасным и гибким, поэтому я (и я думаю, что многие другие программисты) обычно выбирают его для создания больших приложений с некоторой общей бизнес-логикой ... НО! Иногда потеря в скорости до 10 раз! Это просто печально, приложение становится менее отзывчивым, чем могло бы быть.
Поэтому я хочу задать вопрос: можете ли вы поделиться своим собственным опытом создания корпоративных приложений без уровня с веб-сервисами и когда это хороший выбор?

Answer 1

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

Обычные требования для отдельного среднего уровня:

1. Безопасность - иногда веб-сервер находится в DMZ, а средний уровень должен быть в защищенной сети
2. Возможность многократного использования - вы хотите использовать средний уровень в более чем одном приложении, это также приводит к требованию SOA
3. Масштабируемость - средний уровень может быть намного более сложным, поэтому может быть полезно масштабировать его независимо от внешнего уровня. Если вы хотите использовать средний уровень в более чем одном приложении, вы также должны иметь возможность масштабировать его независимо. Требования к масштабируемости обычно основаны на требованиях к производительности и доступности.

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