Выбор архитектуры для CRUD-подобного приложения на WPF
От: alesterre Удмуртия  
Дата: 02.02.12 10:31
Оценка:
Сейчас написано клиент-серверное (двухзвенное) приложение на 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?)

Пока что думаю написать простой прототип, но и сейчас любая информация лишней не будет.

Если кто-то поделится опытом или ссылками на классные источники (вдруг есть в закладках, да и просто "видел там-то у того-то"), буду весьма благодарен.
двухзвенная архитектура трехзвенная архитектура
Re: Выбор архитектуры для CRUD-подобного приложения на WPF
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.02.12 22:29
Оценка: 2 (1)
Здравствуйте, alesterre, Вы писали:

A>В общем, стоит ли менять простую в понимании клиент-серверную архитектуру на заманчивую и более современную трехзвенную?


Однозначно стоит, но далеко не по тем причинам что ты написал.

Чтобы работать в модели клиент-сервер тебе нужно чтобы каждый человек ходил в базу под своей доменной учеткой. тогда у тебя есть хоть какой-то шанс сделать security и аудит. Но для этого нужен хороший DBA, который будет за всем этим следить. кроме того тебе скорее всего потребуется часть логики реализовать в самой БД в виде view, trigger, function, SP, чтобы база вычисляла инварианты, пред- и пост- условия. Иначе в твою БД просто запишут данные какие удобно в обход твоего софта.

В итоге для бизнес-приложений такое мало подойдет.

В этом разрезе тебе гораздо выгоднее трехзвенное приложение, так как в базу ты ходить будешь под одним пользователем, будешь в серверном коде обрабатывать БЛ и вопросы разграничения доступа.


Теперь собственно к архитектуре.

Забудь про виндос сервисы. Тебе нужен веб. Тебе нужен RIA и Silverlight.

Возможно тебе вообще только Lightswitch и нужен.
Re[2]: Выбор архитектуры для CRUD-подобного приложения на WP
От: Visor2004  
Дата: 03.02.12 10:05
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Забудь про виндос сервисы. Тебе нужен веб. Тебе нужен RIA и Silverlight.

G>Возможно тебе вообще только Lightswitch и нужен.

зачем вы советуете человеку огрызки, когда у него есть возможность пользоваться полноценными фреймворками?
Помните!!! ваш говнокод кому-то предстоит разгребать.
Re[3]: Выбор архитектуры для CRUD-подобного приложения на WP
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.12 11:45
Оценка:
Здравствуйте, Visor2004, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:


G>>Забудь про виндос сервисы. Тебе нужен веб. Тебе нужен RIA и Silverlight.

G>>Возможно тебе вообще только Lightswitch и нужен.

V>зачем вы советуете человеку огрызки, когда у него есть возможность пользоваться полноценными фреймворками?


А где тут огрызки? Lightswith — генератор приложений, RIA — по сути тоже. То что нету пары фич WPF в SL ниче не меняет по большому счету.
Re[4]: Выбор архитектуры для CRUD-подобного приложения на WP
От: Visor2004  
Дата: 03.02.12 12:05
Оценка: 47 (2) +2
Здравствуйте, gandjustas, Вы писали:

G>А где тут огрызки? Lightswith — генератор приложений, RIA — по сути тоже. То что нету пары фич WPF в SL ниче не меняет по большому счету.


Ваш совет может сыграть злую шутку с ТС. В теории, конечно, Silverlight — это дйствительно WPF без пары фич, а на практике оказывается, что WPF и Silverlight похожи друг на друга только внешне, а WCF и RIA — это вообще совершенно не похожие вещи. Видел не 1 проект, который начинали делать на Silverlight + RIA, вместо WPF + WCF, рассчитывая получить возможность работы в браузере за гроши и напарывались на довольно сильный гемор, который сводил на нет полезность фичи — работа в браузере.
Если работа в браузере не является одним из основных требованием к проекту (а я так понял, что у ТС именно этот случай), то лучше брать WCF+WPF и нормально работать, чем постоянно оглядываться на ограничения web фреймворков, которые местами очень сильно треплют нервы.
Помните!!! ваш говнокод кому-то предстоит разгребать.
Re[5]: Выбор архитектуры для CRUD-подобного приложения на WP
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.12 12:25
Оценка:
Здравствуйте, Visor2004, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:


G>>А где тут огрызки? Lightswith — генератор приложений, RIA — по сути тоже. То что нету пары фич WPF в SL ниче не меняет по большому счету.


V>Ваш совет может сыграть злую шутку с ТС. В теории, конечно, Silverlight — это дйствительно WPF без пары фич, а на практике оказывается, что WPF и Silverlight похожи друг на друга только внешне, а WCF и RIA — это вообще совершенно не похожие вещи. Видел не 1 проект, который начинали делать на Silverlight + RIA, вместо WPF + WCF, рассчитывая получить возможность работы в браузере за гроши и напарывались на довольно сильный гемор, который сводил на нет полезность фичи — работа в браузере.

Причем тут браузер? Уже давно OOB в SL есть. В чем гемор был?


V>Если работа в браузере не является одним из основных требованием к проекту (а я так понял, что у ТС именно этот случай), то лучше брать WCF+WPF и нормально работать, чем постоянно оглядываться на ограничения web фреймворков, которые местами очень сильно треплют нервы.


Чем лучше? Чем веб-фрейморки треплют нервы? Приведи пример.
Re[6]: Выбор архитектуры для CRUD-подобного приложения на WP
От: Visor2004  
Дата: 03.02.12 16:03
Оценка:
Здравствуйте, gandjustas, Вы писали:

V>>Ваш совет может сыграть злую шутку с ТС. В теории, конечно, Silverlight — это дйствительно WPF без пары фич, а на практике оказывается, что WPF и Silverlight похожи друг на друга только внешне, а WCF и RIA — это вообще совершенно не похожие вещи. Видел не 1 проект, который начинали делать на Silverlight + RIA, вместо WPF + WCF, рассчитывая получить возможность работы в браузере за гроши и напарывались на довольно сильный гемор, который сводил на нет полезность фичи — работа в браузере.

G>Причем тут браузер? Уже давно OOB в SL есть. В чем гемор был?

Дело не в наличие OOВ или его отсутствии. Человек пишет на WPF, вы ему предлагаете перейти на Silverlight, причем в вашей фразе явно присутствует намек на то, что этот переход облегчит жизнь ТС, я же говорю о том, что это не так.

V>>Если работа в браузере не является одним из основных требованием к проекту (а я так понял, что у ТС именно этот случай), то лучше брать WCF+WPF и нормально работать, чем постоянно оглядываться на ограничения web фреймворков, которые местами очень сильно треплют нервы.

G>Чем лучше? Чем веб-фрейморки треплют нервы? Приведи пример.

Silverlight треплет нервы WPF разработчику тем, что инструменты которые позиционируется как эквивалентные для wpf имеют слишком много отличий и их поведение часто не такое же как в Wpf аналогах. Отсюда же следует и то, что большая часть кода из wpf приложения просто не будет компилироваться, а потом еще и работать как работала, а ТС явно озвучил ненулевую вероятность расширения кодовой базы уже существующего приложения.
За примерами далеко ходить не надо, в Wpf в стилях и шаблонах принято широко использовать триггеры, в silverlight такого нет.
Про сравнение RIA и wcf я надеюсь вопросов все же не возникло.
Помните!!! ваш говнокод кому-то предстоит разгребать.
Re[7]: Выбор архитектуры для CRUD-подобного приложения на WP
От: alesterre Удмуртия  
Дата: 03.02.12 17:51
Оценка:
>Здравствуйте, Visor2004, Вы писали:
>Здравствуйте, gandjustas, Вы писали:

Спасибо за мнения. Сделаю прототип на WPF + WCF, там будет видно. Насчет Silverlight думал, но как-то не хочется столкнуться с какими-то ограничениями (то же самое, и даже в большей степени, можно сказать про Lightswitch) по сравнению с WPF, да и не работал с ним серьезно. Плюс, действительно, задача работы в браузере никем не ставится. Но еще подумаю.
Re[7]: Выбор архитектуры для CRUD-подобного приложения на WP
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.12 18:19
Оценка: -1
Здравствуйте, Visor2004, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:


V>>>Ваш совет может сыграть злую шутку с ТС. В теории, конечно, Silverlight — это дйствительно WPF без пары фич, а на практике оказывается, что WPF и Silverlight похожи друг на друга только внешне, а WCF и RIA — это вообще совершенно не похожие вещи. Видел не 1 проект, который начинали делать на Silverlight + RIA, вместо WPF + WCF, рассчитывая получить возможность работы в браузере за гроши и напарывались на довольно сильный гемор, который сводил на нет полезность фичи — работа в браузере.

G>>Причем тут браузер? Уже давно OOB в SL есть. В чем гемор был?

V>Дело не в наличие OOВ или его отсутствии. Человек пишет на WPF, вы ему предлагаете перейти на Silverlight, причем в вашей фразе явно присутствует намек на то, что этот переход облегчит жизнь ТС, я же говорю о том, что это не так.


Я говорю что RIA облегчит жизнь. WPF или SL — разницы не будет, но реализация RIA на клиенте есть штатно для SL.

Я но понимаю почему ты утверждаешь что это чем-то помешает. У тебя есть примеры?

V>>>Если работа в браузере не является одним из основных требованием к проекту (а я так понял, что у ТС именно этот случай), то лучше брать WCF+WPF и нормально работать, чем постоянно оглядываться на ограничения web фреймворков, которые местами очень сильно треплют нервы.

G>>Чем лучше? Чем веб-фрейморки треплют нервы? Приведи пример.

V>Silverlight треплет нервы WPF разработчику тем, что инструменты которые позиционируется как эквивалентные для wpf имеют слишком много отличий и их поведение часто не такое же как в Wpf аналогах.


Ты о чем? Конкретнее говори.

V>Отсюда же следует и то, что большая часть кода из wpf приложения просто не будет компилироваться, а потом еще и работать как работала, а ТС явно озвучил ненулевую вероятность расширения кодовой базы уже существующего приложения.


А причем тут портирование? ТС собирается создавать новое приложение.

V>За примерами далеко ходить не надо, в Wpf в стилях и шаблонах принято широко использовать триггеры, в silverlight такого нет.

А причем тут шаблоны WPF если создавать приложение SL?

V>Про сравнение RIA и wcf я надеюсь вопросов все же не возникло.


Ты о чем?

Странный ты какой-то. Приводишь пространные рассуждения уже третий пост не сказав ничего что хоть как-то к вопросу относится.
Re[8]: Выбор архитектуры для CRUD-подобного приложения на WP
От: Visor2004  
Дата: 03.02.12 20:38
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

забей, я больше для ТС писал, он, судя по последнему посту, меня понял
Помните!!! ваш говнокод кому-то предстоит разгребать.
Re[6]: Выбор архитектуры для CRUD-подобного приложения на WP
От: Lepsik Гондурас https://www.kirdyk.club/
Дата: 03.04.12 20:23
Оценка:
---на практике оказывается, что WPF и Silverlight похожи друг на друга только внешне

Silverlight team in Microsoft not exists anymore. So..
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.