Какая архитектура / технология / шаблон лучше всего подходит для такого рода сценариев?
Поскольку это звучит в основном как приложение только для чтения, а не как то, что будет выполнять ввод данных иПроверка, я бы, вероятно, выбрал WPF (10 клиентов не так много).Silverlight будет моим вторым выбором.Любая технология даст вам асиновые обратные вызовы.Я сделал оба;WPF будет более отзывчивым.
Должен ли я использовать WPF, Windows Forms или Silverlight?
Избегать WinForms, как чума.
Должны ли предварительно рассчитываться представления на сервере или клиент должен выполнить эту обработку?
Это зависит от того, какую работу вы хотите выполнить с базой данных.Лично я ненавижу помещать бизнес-логику в базу данных ... Я бы, вероятно, написал упрощенный Service Facade поверх БД, поместил туда свою бизнес-логику и затем представил бы результаты в виде службы WCF клиенту WPF (или какСервис RIA, если я выбрал Silverlight).
Должен ли клиент подключаться напрямую к базе данных или через службу WCF?
Подключение напрямую к БД означает, что вы собираетесь в HAVE, чтобы поместить всю бизнес-логикулибо в БД в views / Sprocs, либо все вычисления должны быть на клиенте (плохо, IMO).Или разложить по двум (хуже).
Лично мне бы хотелось, чтобы вся бизнес-логика находилась в одном месте на сервере, чтобы клиенты, получающие данные, гарантированно получали ТО ЖЕ САМЫЕ результаты.Я не позволил бы клиентам делать расчеты данных.
РЕДАКТИРОВАТЬ: Кроме того, наличие у клиентов ЛЮБОГО вида бизнес-расчетов затрудняет развертывание и управление версиями.Если вы ЗНАЕТЕ, что вся бизнес-логика находится на сервере, то все, что вам нужно сделать для обновления, - это выпустить новую версию сервиса.Тогда вам все равно, сколько у вас клиентов и кто в какой версии клиентского приложения - вы все равно можете гарантировать, что клиенты получают самые новые данные через одну службу.
Я бы, вероятно, либо построил бы представления в БД для наборов результатов (если бы вычисления данных были простыми и легко подходили для представлений), либо на стороне сервера была бы служба, которая выполняла бы вычислениякаждые X минут, а затем кэшировать эти результаты (кешировать в другие таблицы, или другую БД, или нет-sql, что угодно).В этом случае клиенты могут получать данные так часто, как им хочется, но вычисление данных будет фактически контролироваться службой, а не клиентами.Позволить клиентам управлять обновлением данных может быть ошибкой ... Единственный способ, который я считаю приемлемым, - это если вы добавите какой-то механизм регулирования в свои сообщения, чтобы вы могли сказать клиентам: «Не пингуйте менятак быстро для результатов, сервер отстает ".Потому что сервер должен иметь некоторый контроль над нагрузкой.
В этом сценарии есть над чем подумать, и это только мои первые мысли.