Архитектура приложения клиент, прошу совета

Ситуация - есть некий программный сервер с БД и текущими состояниями массива объектов.
Приложение цепляется к нему по WCF.
Приложение имеет интерфейс пользователя для отображения данных с сервера в табличном виде, в виде списка параметров (в зависимости от запроса), передачи данных на сервер для инициации каких-либо действий сервером или изменения данных в БД.
Сейчас реализован интерфейс Wcf и необходимые DataContract для обмена данными. DataContract представляют собой массивы классов содержащих поля данных. Это сделано в виде отдельной DLL, подключаемой и к серверу, и к приложению.
Запнулся на этапе построения архитектуры приложения. Я вижу:
1) Класс-клиент Wcf, организующий связь с сервером и использующий методы интерфейса для обмена данными;
2) Класс-хранилище настроек приложения (с сохранением настроек во внешнюю среду);
3) Интерфейс пользовательского интерфейса;
4) Реализация интерфейса пользовательского интерфейса (сори за тафталогию);
5) Класс рабочего потока (при необходимости несколько) - организующий связи между компонентами программы в том числе в нескольких потоках;
6) Собственно сам пользовательский интерфейс (сейчас - WinForm).

Передавать данные в пользовательский интерфейс планирую в виде DataTable или массива строк в зависимости от запроса. Из пользовательского интерфейса в рабочий поток либо строки, либо вызывать функции без аргументов. Необходимые проверки строк и их преобразование делать в классе, реализующем интерфейс интерфейса.

Прошу оценить данную концепцию.

0

aquaMakc, не все понял, но как я бы сделал.
1. Класс-менеджер клиента. Внутренне использует либо сгенерированный класс по метаданным сервера, либо канал будет создаваться на лету через ChannelFactory<T>.
Так же менеджер клиента должен содержать метод проверки работоспособности сервера (на случай, если он отвалился и не работает).
2. Хранилище настроек - класс-синглтон.
3. Собственно пользовательский интерфейс, работающий с менеджером клиента.
По поводу контрактов данных-у вас они уже есть, в отдельной либе.
Что касается остального-я не понял.

0

Сообщение от aquaMakc Передавать данные в пользовательский интерфейс планирую в виде DataTable

А зачем вам DataTable, если у вас уже есть классы DTO (те которые в вашем DataContract) ?

интерфейс интерфейса - Шото страшное.
тафталогия -> тавтология

0

Сообщение от Storm23 тафталогия -> тавтология

))) спасибо

Сообщение от Storm23 интерфейс интерфейса - Шото страшное.

имеется ввиду interface, от которого планирую унаследовать класс, отвечающий за работу с формочкой. Если честно, особой необходимости не вижу, скорее для эксперимента и вполне готов отказаться от лишней абстракции.

класс, отвечающий за работу с формочкой != класс формы. Это класс, которому эта форма принадлежит

Сообщение от Storm23 А зачем вам DataTable

Т.к. в планах поддержка нескольких языков интерфейса (опять - таки для эксперимента), DataTable хочу создавать на основе этих самых DataContract, но в нужном мне виде, передавать в форму и там присваивать их DataSource`ам DataGridView.

0

Сообщение от Storm23 зачем вам DataTable

Тоже хотел задать этот вопрос)))
DataTable - NET-овский тип, зачем его выводить за границы службы? Используйте нейтральные сущности, к примеру массивы. Или, как сказано выше, ваши контракты данных.

0

Сообщение от insite2012 Или, как сказано выше, ваши контракты данных

Я хочу максимально автоматизировать вывод больших данных на форму. Форма данные получила, в DataSource нужной DataGridView засунула и всё и без предварительной их настройки. Если я буду указывать источник DataContract - заголовки столбцов будут соответствовать именам свойств, отображаться будут все без исключения данные (которые в некоторых случаях надо скрывать), да и порядок их будет точно соответствовать указанному в контракте.
Формировать же DataGridView из контракта в классе формы я не хочу.

0

Сообщение от aquaMakc Если я буду указывать источник DataContract - заголовки столбцов будут соответствовать именам свойств.

Ну вообще-то имя столбца в DGV можно задавать с помощью атрибута [DisplayName] в свойстве. Т.е. заголовок столбца может быть отличным от имени свойства.

Сообщение от aquaMakc Формировать же DataGridView из контракта в классе формы я не хочу.

Ну смотрите, вам все равно где-то придется преобразовывать свои DTO в вид пригодный для формы.
Если сами DTO не подходят, то для них делается враппер, который будет давать наружу нужные свойства с нужными названиями. И в форму передается список/массив таких объектов.
Вы же все равно будете делать то же самое, но с той разницей, что DataTable - слабо типизированный объект и с ним работать немного сложнее чем с типизированным списком, ИМХО.
Впрочем, не видя код тут трудно что сказать. Будет код - можно будет оценить более предметно.

1

Сообщение от Storm23 Ну вообще-то имя столбца в DGV можно задавать с помощью атрибута [DisplayName] в свойстве

Я знаю, но не хочу вообще руками прикасаться к DGV.

Сообщение от Storm23 Если сами DTO не подходят, то для них делается враппер, который будет давать наружу нужные свойства с нужными названиями.

Хорошая идея.

Сообщение от Storm23 Впрочем, не видя код тут трудно что сказать. Будет код - можно будет оценить более предметно.

Код в процессе создания. Хочу предварительно с архитектурой определиться.

Остановлюсь наверно, на врапперах, а interface для диспетчера окошек пока задвину под комод. "Скрипач не нужен" ©

Добавлено через 4 минуты
Да, кстати...

Сообщение от aquaMakc свойства с нужными названиями

Очень не хочется в обёртках свойствам давать имена на русском, хотя знаю, что можно. Этому есть рациональное объяснение, или я зря переживаю?

0

Сообщение от aquaMakc Очень не хочется в обёртках свойствам давать имена на русском, хотя знаю, что можно

Еще раз: Атрибут [DisplayName]

2