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

Question

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

2

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

0x49D1 10 апр. 2011, в 12:31

Источник

Теги:

c#

architecture

entity-framework

wcf

n-tier

1 ответ

Ещё вопросы

Ladislav Mrnka · Accepted Answer · 2011-04-10T08-02-00.000Z

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

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

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

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

Очень хороший ответ. Я обычно не хочу одного и того же бизнес-уровня в нескольких приложениях. Но безопасность .. Вот проблема. Клиенты обычно имеют закрытый сервер с базой данных, и клиентские компьютеры должны быть в VPN, чтобы напрямую к нему добраться. А с помощью сервисов мы можем подключить к VPN только один сервер и подключиться к нему с клиентских компьютеров через «открытый» веб. Безопасность всегда влияет на скорость. Эх .. А клиенты хотят большей отзывчивости! Хорошо ... попробую спросить о приемлемых условиях для таких решений (например, хороший канал между сервисным сервером и базой данных один и хороший сервисный сервер для работы со всеми клиентами)
Но разве это не хорошее решение: защитить себя от изменений клиентов и будущих n-уровневых приложений для создания требований (наверняка потребуется немного больше времени)? Почти всегда клиенты хотят продолжить некоторые проекты и добавить некоторые функции, которые могут привести к изменению уровня 2 на 3 или более. Кажется, что гибкость ПОЧТИ всегда хорошая идея.
@nihi: Это зависит от вашего подхода к разработке и реального опыта работы с вашим клиентом. Гибкость - хорошая идея, но в то же время вы не должны разрабатывать то, что клиент не хочет в данный момент (гибкая школа), потому что в то же время вы можете позже обнаружить, что это пустая трата времени, так как никакие дальнейшие изменения не требуют 3-уровневого уровня. применение.