Сейчас написано клиент-серверное (двухзвенное) приложение на WPF и Entity Framework для редактирования автобусных расписаний. Все устраивает, кроме проблемы одновременного доступа, например, если кто-то редактирует расписание, а кто-то другой его в это время удаляет. Поскольку пользователей немного, и, как правило, каждый отвечает за свой набор расписаний, сделал простую блокировку — при открытии расписания следующий пользователь может открыть только для просмотра. Работает не идеально, но просто в реализации и особых проблем не доставляет (в худшем случае — падает клиентское приложение).
В ближайшем будущем нужно написать другое приложение (либо встраивать новый функционал в текущее), там пользователей уже будет больше. Хочется решить проблему одновременного доступа более надежным способом. Более того, хочется, чтобы изменения одного пользователя в реальном времени отображались в интерфейсах других пользователей (как, например, в Google Docs, только без редактирования текста в реальном времени). Кроме того, нужно автоматически обрабатывать новые данные, поступающие извне. Заталкивать эту обработку в хранимые процедуры как-то совсем не хочется.
Сразу подумал о трехзвенной архитектуре: клиентские приложения на WPF почти без логики, которые через WCF подключаются к среднему звену на сервере (через двухстороннюю связь, чтобы транслировать клиентам обновления данных), в котором сосредоточена вся логика, а среднее звено через EF работает с базой данных. Обмен данными между клиентом и сервером приложений — через Self-Tracking Entities (клиенты пишутся только на .net).
Теперь вопросы:
1) Жизнеспособна ли такая архитектура, или я упускаю что-то важное (посмотрел отдельно примеры по WCF, STE, вроде то, что нужно, но описания решения в целом нигде не видел).
2) Не променяю ли я сложность синхронизации клиентов в двухзвенной архитектуре на сложность реализации трехзвенной архитектуры, и если променяю, стоит ли оно того (классические преимущества трехзвенки, типа масштабируемости и легкой возможности замены клиента для меня малоприменимы).
3) Как вообще ведется разработка серверной части?
Вот я сейчас как пишу клиентское приложение:
— реализую кусочек функционала,
— запускаю, проверяю,
— если все ок, делаю commit и push в меркуриале
— делаю паблиш через ClickOnce
— пользователи сами загружают новую версию при старте программы
— время от времени смотрю логи пользователей/тестировщиков, все ли ок
А если я пишу сервер приложений (среднее звено, сервис WCF, как это вообще правильно называть), допустим, я хочу, чтобы он в итоге работал как служба Windows на сервере и сам перезагружался после падения (а падения будут, особенно много поначалу), то вот что меня отпугивает: я же не смогу так просто запустить из студии серверную часть, проверить, что-то поменять, снова проверить. Мне придется каждый раз куда-то устанваливать эту службу и перезапускать. Не потрачу ли я на это слишком много времени (по сравнению со старым добрым клиент-серверным подходом, где сервер БД живет своей жизнью, а отладка клиента тривиальна)? Или делать поначалу как консольное приложение? Его не надо никуда устанваливать, запустил и все.
В общем, стоит ли менять простую в понимании клиент-серверную архитектуру на заманчивую и более современную трехзвенную?
(Если честно, хочется поменять, хотя бы ради опыта, вопрос в том, чего мне это будет стоить, у начальства терпение тоже не безграничное, у них денег на крутых специалистов нет, но результат-то нужен, в связи с этим они готовы пожертвовать 100% качеством ПО, то есть, "можно делать как попало, потом разберемся, лишь бы уже работало". Но по срокам сильно не давят, определенное пространство для маневра есть. Так, например, Entity Framework уже сэкономил мне прорву времени, хотя я и изучал его прямо по ходу дела. Сэкономит ли мое время WCF?)
Пока что думаю написать простой прототип, но и сейчас любая информация лишней не будет.
Если кто-то поделится опытом или ссылками на классные источники (вдруг есть в закладках, да и просто "видел там-то у того-то"), буду весьма благодарен.
