Пользовательский интерфейс и прикладная связь

Question

Я читал много статей о пользовательском интерфейсе, логике логистики, WCF, IoC, но все же одна вещь отсутствует в моем сознании. Я создаю приложение winforms и консольное приложение. Консольное приложение - это мозг. Теперь во всей клиент-серверной архитектуре клиент «знает» сервер, отправляет ему запрос и получает ответ. Мой вопрос заключается в следующем:

1) Как приложение консоли может отображать сообщение пользователю, если он не знает о существовании пользовательского интерфейса? Должен ли пользовательский интерфейс проверять и пул сообщений для сообщений каждые x мсек? это хороший подход?

2) что в случае, если в форматах пользовательского интерфейса должна отображаться цена тикера, например, цена акций, которая постоянно изменяется? следует ли запрашивать цену тикера из консольного приложения каждые 200 мсек? или зарегистрировать функцию обратного вызова в консольном приложении, чтобы консольное приложение могло вызвать ее? Однако не превращает ли пользовательский интерфейс в сервер?

3) Что произойдет, если я хочу добавить терминальные возможности в приложение (например, telnet cli), как его создать? сервер telnet в качестве клиента и мое консольное приложение в качестве сервера? есть ли дизайн, который может помочь мне достичь этого? ТАКСИ? Я спросил много людей, и кажется, что никто не использует его ... это так?

Спасибо, Эяль

Answer 1

Ваша программа должна быть спроектирована таким образом, чтобы вы могли заменить один пользовательский интерфейс на другой. Программа должна иметь логическую функцию независимо от интерфейса, который видит пользователь. Взгляните на модели MVC и Observer.

Одним из хороших показателей вашей программы является интерфейс, предоставляемый пользователю [вызовы API, консольный GUI, консольный интерфейс, сетевой интерфейс, сеть]. Я не подразумеваю, что вы должны переориентировать намерение приложение должно сделать его очень гибким с интерфейсом. Я предполагаю, что ваш интерфейс не должен иметь ничего общего с логикой и хранилищем данных вашего приложения.

Stock ticker: У вас есть шаблон обсервера, который транслирует новое событие каждые 200 мс или изменения. Представление тикера будет подписчиком этих событий.

Answer 2

Почему бы вам не создать «мозг» в качестве библиотеки? Интерфейс WinForms и консольное приложение являются интерфейсами пользователя и должны быть отделены от логики. Это позволяет упростить доступ к функциям, и вы также можете подписаться на события.

Answer 3

Вам следует избегать архитектуры, которую вы созерцаете. Создание двух отдельных процессов для совместной работы сложно. Операционная система создает большую стену между процессами, чтобы убедиться, что один неверный процесс не может дестабилизировать другой. Каждый процесс имеет свой собственный вид памяти, особенно Windows (и .NET) очень затрудняет обмен файлами между процессами.

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

Вы можете получить то, что хотите от одного приложения. Класс System.Threading.Thread дает вам моральный эквивалент вашего приложения в режиме консоли.Получение пользовательского интерфейса для отображения сообщений из потока мозга довольно просто с помощью фона BackgroundWorker или метода Control.Begin/Invoke(). Только «честно» btw, получив правку на поток, по-прежнему прилагается.

Существует два способа получить обновление биржевого тикета. Толкание и тяговый подход. Подход push позволяет фоновому потоку активно уведомлять поток пользовательского интерфейса, что обновление доступно. BackgroundWorker.ReportProgress или Control.Begin/Invoke для этого. При обновлениях в 200 мсек это не проблема.

При таких ставках модель тяги будет работать так же хорошо. Вы должны использовать Таймер в пользовательском интерфейсе, чтобы периодически запускать метод. Он мог бы прочитать значение из общего свойства в методе Tick Tick. Вам нужно будет использовать оператор блокировки как в фоновом потоке, так и в методе Tick, чтобы гарантировать, что значение не может измениться, так как поток пользовательского интерфейса читает значение.

Вы должны одобрить модель тяги, когда значение может меняться очень быстро, нажав на скорость, которая приведет к тому, что поток пользовательского интерфейса будет вставать на колени, когда время, необходимое для обновления пользовательского интерфейса, больше, чем период между обновлениями из фонового потока , Поток пользовательского интерфейса будет отставать и не будет соответствовать его нормальным обязанностям. Замороженный интерфейс - это диагностика, конечным результатом является OOM. 200 мс не должно быть проблемой, если вы не будете очень причудливы или небрежны с обновлениями пользовательского интерфейса, push должен работать.

Мне нужно присоединиться к лиге друзей, с которыми вы консультировались по серверам telnet. Не уверен, какие проблемы они решают, они эквивалент 1990 года веб-сервера, когда все используют зеленый экран для разговора с компьютером. Возможно, это связано с необходимостью подключения отдельного приложения режима консоли к пользовательскому интерфейсу. Вы бы не использовали telnet для этого, сокет - это общий канал. .NET Remoting или, лучше, WCF - это слой, который находится поверх этого канала, чтобы избежать необходимости усложнять сжатие данных или параметров метода через трубу байтов. Преследуйте это, если вы полностью вложены в многопроцессное решение. Вы не должны быть для приложения для акций, никто не заботится о том, как они помечают, если на них нет никого, чтобы посмотреть на них. Возможно, падение дерева в лесу.