Считаете ли вы, что текущий дизайн программного обеспечения является правильным?
Вероятно, объективно «правильного» дизайна не существует - есть только лучшие или худшие дизайны. :) Похоже, вы на правильном пути, но я бы посоветовал вам оставить свой графический интерфейс и представления отделенными от серверных сервисов. Например:
View --- Controller --- Service
Таким образом, View знает только, как отображать вещи (например, сообщения IM, веб-контент или что-то еще) и передает запросы от пользователя к Controller. Controller получает уведомления от Service и обновляет View. Service ничего не знает о внешнем интерфейсе (так что он может быть скриптовым, что очень полезно) и просто реализует протокол, необходимый для взаимодействия с сетевым сервисом. У вас будет отдельный набор этих трех классов для каждой отдельной серверной системы и общий контроллер для управления приложением на глобальном уровне.
Кажется, очень трудно связать все View / Controller с каждой частью модели, это нормально, что для этого требуется так много работы?
Вероятно, да - вы пытаетесь нетривиальное приложение. Я предполагаю, что вы используете архитектуру в стиле MVC. Это может потребовать больше работы, чтобы должным образом отделить вещи, но это определенно стоит того. Чем сложнее ваше приложение, тем больше вы выиграете от наложения и разделения.
Было бы лучше создать новый поток для каждого запроса к услуге?
Учитывая, что все сервисы основаны на сети, вам нужно помешать блокирующим вызовам ввода / вывода (таким как чтение сокетов) блокировать ваш основной поток графического интерфейса. Поэтому вам нужно либо использовать полностью асинхронный ввод-вывод с обратными вызовами в одном потоке (не очень часто), либо иметь отдельный поток для каждого сетевого сеанса (наиболее распространенный подход). Я бы не рекомендовал создавать новый поток для каждого отдельного запроса, но для всего сеанса. Вы должны быть осторожны, чтобы избежать обычных проблем с многопоточностью, таких как условия гонки и взаимоблокировки (эта тема может заполнить книгу). Поток должен будет отправить сообщение обратно в графический интерфейс для уведомлений, так как вы не можете обновить свой графический интерфейс из контекста другого потока.
(например, TDigg получает сообщение от кнопки, создает поток, который создаст TidHTTP, сгенерирует запрос к серверу, дождется ответа, проанализирует ответ, отправит сообщение каждому наблюдателю (обратный вызов) и затем освободите нить.
Звучит так, будто ваш GUI соединен с контроллером и обработчиком протокола. Я предлагаю вам отделить интерфейс и бэк-энд и оставить все как есть.
Если я воспользуюсь предыдущей идеей, не создаст ли она слишком много потоков и сделает компьютер медленным и менее ответственным?
Потоки обычно используются, чтобы сделать компьютер более отзывчивым. Создание потоков имеет определенные накладные расходы и требует большой осторожности для правильной синхронизации. Но если у вас есть один поток на сетевую сессию, накладные расходы не замедлят работу, поскольку у вас будет всего несколько.
Достаточно ли хорош SQLite 3 для хранения всех данных на клиенте? (данные могут быть письмами, новостными лентами и т. д., поэтому со временем может быть много данных).
SQLite - отличная база данных для этой цели. Он используется некоторыми из крупнейших в мире компаний по разработке программного обеспечения для управления хранилищем на стороне клиента. Это очень быстро и эффективно, и я уверен, что оно сможет идти в ногу с вашим приложением.
Вы, кажется, предпринимаете сложное заявление. Я предлагаю вам купить книгу по параллельному программированию и прочитать еще несколько статей о потоках. Это очень сложная проблема, которая может привести к ошибкам, которые невероятно сложно отследить, если не запрограммированы с большой осторожностью. Удачи!