Что такое хорошая архитектура для серверного сервиса и графического интерфейса?

Question

Я создаю приложение, которое позволяет пользователям выполнять некоторые команды на компьютере, отправляя их по электронной почте. Сервер будет отслеживать (извлекать) одну или несколько учетных записей электронной почты и начинать сеанс связи. Некоторая аутентификация также участвует. Я использую новейшие и лучшие технологии .net.

Я думаю представить сервер как службу, но тогда у меня не будет графического интерфейса пользователя, чтобы позволить пользователю настраивать такие вещи, как пароли и учетные записи электронной почты. Как я могу отделить их?

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

Answer 1

Я использовал WCF, текущую технологию Microsoft для реализации веб-сервисов и / или SOA. Вы должны создать настольный клиент или веб-страницу, которая выполняет вызовы к службе WCF. Службы WCF будут вашим компонентом сервера, а клиент рабочего стола или веб-страница - вашим пользовательским интерфейсом.

Answer 2

Это в основном не вопрос того, как сделать сам сервис. И протокол связи не является главной проблемой - с WCF вы можете раскрыть свои методы приложения через спектр протоколов. Это просто вопрос конфигурации приложения.

Главный вопрос здесь: как вам нравится реализовывать GUI? Если ваше приложение представляет собой обычную службу Windows, то оно не может иметь встроенный графический интерфейс. Просто потому, что сервис не должен его иметь. Так что вам понадобится отдельное приложение с графическим интерфейсом. Опции:

1. GUI - это отдельное приложение .NET, которое каким-то образом взаимодействует с вашим сервисом. Скажем, через WCF. В этом случае плагины также должны быть реализованы в двух частях: плагин для сервиса и плагин для GUI. Я думаю, это было бы слишком сложно для поддержки.

2. Модификация 1-го варианта. И сервис, и графический интерфейс упакованы в один исполняемый файл. Он смотрит в каком режиме он запущен (сервисный или автономный) и либо отслеживает почту, либо показывает графический интерфейс. Поскольку это одно приложение, конфигурация также одинакова. Таким образом, у вас будет единый реестр для плагинов. Я предполагаю, что в режиме GUI приложение будет искать запущенный сервис и настраивать его. Недостаток - графический интерфейс может быть запущен только локально.

3. Вы делаете некий «переносимый» GUI - сервис отправляет GUI простому клиенту, который показывает это. В этом случае у вас есть одно место для всего кода приложения (службы и графического интерфейса), но оно выполняется частично в службе, частично в клиентском программном обеспечении. Но вам также нужно такое универсальное клиентское программное обеспечение.

4. Подумав еще немного о варианте 3, мы видим, что решение уже существует - это веб-технологии. Было бы проще реализовать ваш сервис как часть веб-сайта. И графический интерфейс будет другой частью. Если вы не знакомы с HTML и Javascript, вы можете реализовать графический интерфейс с помощью Silverlight.

5. Фактически, вы можете разместить ASP.NET прямо в вашем сервисе. Вот хорошее объяснение . Но, боюсь, это добавляет ненужную сложность