Лучшая практика для обработки больших услуг WCF

Question

Я работаю над сетевой игрой для 4 игроков в WPF и изучаю WCF в процессе. До сих пор, чтобы справиться с сетевым взаимодействием, я следовал совету игры YeahTrivia для игры Coding4Fun : я использую dualHttpBinding и использую интерфейс CallbackContract для отправки сообщений клиентам , Это работает довольно хорошо.

Однако мой сервис становится очень большим. У него есть методы / обратные вызовы для управления самой игрой, а также система чата, процесс входа в систему / регистрации, создание матчей, информация о ростере / игроке и т. Д. Как сервер, так и клиент становятся сложными в обслуживании, потому что все связано с Единый интерфейс. Например, на клиенте я должен перенаправить обратные вызовы либо на страницу игры, на страницу лобби и т. Д., И я считаю это очень утомительным. Я предпочел бы иметь возможность обрабатывать обратные вызовы игры на странице игры, обратные вызовы чата в окне чата и т. Д.

Так, каков лучший способ справиться с этим? Я думал о многих вещах, но не уверен, что лучше: разбить службу на несколько, иметь несколько «конечных точек» на моем сервисе, или есть другие приемы, чтобы реализовать сервис частично там, где это необходимо?

Спасибо

Answer 1

У вас должно быть несколько компонентов, каждый из которых должен быть ограничен одной ответственностью - не обязательно одним методом, но обработкой состояния для одного из объектов, с которыми вы имеете дело. Когда у вас есть все в одном сервисе, ваш сервис невероятно связан с самим собой. Оптимально, каждый компонент должен быть как можно более независимым.

Я бы сказал, начните с того, что разделите его там, где это имеет смысл, и все должно быть НАМНОГО более управляемым.

Answer 2

Я бы поддержал ответ Терри - вам обязательно нужно разделить ваш большой интерфейс на несколько меньших.

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

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

Марк