Разделение бизнес-логики презентации на разных серверах/уровнях

Question

Я вынужден использовать хостинговую компанию, которая заставляет меня отделять мою (веб-) логику представления и мою бизнес-логику на двух разных серверах/уровнях, разделенных брандмауэром. Доступ к Интернету будет только сервер с логикой представления. Обоснованием является безопасность. У меня есть третий сервер/уровень с БД, но это тривиально. Я ищу образцы архитектуры/дизайна, которые полезны в этом сценарии.

Я нашел описание от Microsoft на трехуровневой веб-архитектуре: Improving Web Application Security: Threats and Countermeasures, но это о том, что делать, а не , как, чтобы сделать это. Собственный хост Microsoft использует двухуровневую архитектуру: Windows Azure Security Guidance.

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

Что такое умный способ сделать это? Может ли кто-нибудь дать мне ссылку на статью и т. Д.?

Answer 1

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

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

Вы: : Включение бизнес-логики в зону зрения/контроллера, поскольку состояние сеанса гораздо удобнее находится там. Помните об этом и работайте над его контролем.

Шаблон MVVM может соответствовать этому намного ближе, чем MVC, и он лучше справляется с инкапсулированием состояния представления на стороне бизнес-сервера. Тем не менее, сеансы все еще не решены. Вам понадобятся отдельные секции на уровне представления/бизнеса, но один из них на слое будет очень легким. В основном просто нужно обрабатывать аутентификацию, а затем иметь ключ (sessionid), который он может передать на уровень сервиса, чтобы позволить viewmodel связываться с.