Как обслуживать одноэлементный объект по сети в C #?

Question

Я создаю карточную игру на C # для школьного проекта. Эта карточная игра в сети. Данные игры в карточную игру хранятся в одноэлементном объекте как gameData. gameData содержит имена игроков, на которых ожидает игра, объекты игроков. У каждого игрока есть 3 объекта списка. Где на карточках опять заказные предметы. Первоначально я собирался создать метод ToByte () для каждой карты, игрока и объекта gameData и сериализовать их для отправки по сети с помощью TCPlistener. Однако иссякает вовремя, я ищу другие пути.

Вот решения, о которых я слышал:

-SOAP (понятия не имею, как это реализовать)

-Database (кажется чрезмерным для локальной сети, если только небольшой сервер баз данных не может быть запущен на лету)

-Клиент Активированный объект (но это создает разные синглтоны для каждого клиента)

Я хотел бы, чтобы каждый клиент использовал свои собственные данные gameData, но используя get, установил, что он будет взаимодействовать с сервером, на котором размещены эти данные объекта-одиночки. Что вы рекомендуете?

Answer 1

WCF поддерживает одноэлементные сервисы

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)] 
class MySingleton : ...
{...}

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

WCF упрощает сетевое взаимодействие с очень небольшим количеством сетевого кода.

Проверьте эту статью для более подробной информации.

Объедините экземпляр синглтона с любым учебным пособием WCF, и вы получите хорошую отправную точку.

Удачи.

Answer 2

Так как это школьный проект, я думаю, что использование .NET remoting - самый быстрый путь:)

Чтобы упростить задачу и уменьшить количество неприятных отладочных и управляющих объектов, я бы предложил обрабатывать все на сервере с помощью одноэлементного объекта и возвращать маршалы по объектам-значениям клиентам в качестве данных (опять же, поскольку это школьный проект). Дайте каждому клиенту идентификатор для передачи на объект сервера.

Answer 3

Я бы полностью избежал синглтона. Это не только боль удаленного взаимодействия, но и в любом случае часто считается плохим дизайном. Здесь много дискуссий на SO и в Интернете о том, почему синглтон плох. Я думаю, особенно в этой ситуации, если синглтон создаст вам проблему, избегайте ее.

[Редактировать] Одним из основных мотивов отказа от синглтона является то, что синглтон обеспечивает общее глобальное состояние, которое является врагом юнит-тестирования. Избегайте этого, когда это возможно.

Answer 4

.net удаленное взаимодействие более или менее построено для того, о чем вы просите, но не обязательно для того, что вам нужно.

Любой удаленный доступ к классу оставит вас с «синглтоном» на другом конце провода на самом деле вовсе не синглтоном, а заглушкой прокси в локальной памяти.

В вашей ситуации я бы добавил класс сервиса (возможно, веб-сервис), который принимает входящие запросы и применяет их к синглтону на стороне сервера, а затем возвращает необходимые данные. Это спасет вас от отладочной боли.