Как вы структурировали свои сетевые приложения?

Question

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

Пожалуйста, опишите основную архитектуру и / или структуру классов. Вы абстрагировали коммуникационные биты? Какие классовые сущности вы придумали?

Приложение будет иметь классы слушателя и клиента. Он похож на агрегатор каналов, но использует постоянные соединения, а не HTTP. Другими словами, я подключаюсь к сокету и имею постоянное соединение, в котором данные передаются в обоих направлениях. Тогда у меня также есть клиенты, которые постоянно подключаются ко мне, и я посылаю им некоторые (или все) данные.

Кроме того, я не могу использовать WCF или что-либо из .NET 3.0 или 3.5 (хотя я могу использовать C # 3, потому что я занимаюсь разработкой на VS2008). Я должен быть совместим с Windows 2000.

Answer 1

«Сетевое приложение» - неясная категория, охватывающая довольно широкий спектр возможных требований и конструкций. По определению вам придется иметь дело с параллелизмом и задержками. Надежность - это всегда сложная задача: слишком легко спроектировать систему, доступность которой является наименьшим общим знаменателем из всех ее аппаратных и программных компонентов. Вам нужно будет обновить операционную систему и компоненты вашего приложения: можете ли вы отказаться от всего решения, или вам нужен какой-нибудь режим горячего / холодного резервирования или даже отказоустойчивость? Сети выходят из строя экзотическими способами (по крайней мере, нам, бедняжкам, занимающимся чистым программным обеспечением): вы зависите от многих вещей, о которых никогда не задумывались (маршрутизаторы, коммутаторы, DNS-серверы, характер этого бородатого сетевого инженера в коридоре!), И должны разработать взаимодействие с пессимистическим настроем.

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

Две общие рекомендации книги:

• Проектирование параллельных, распределенных приложений и приложений реального времени с использованием UML уже несколько лет, но оно приносит домой проблемы, с которыми вы можете столкнуться (особенно если у вас действительно есть жесткие или мягкие зависимости в реальном времени где-то ). Немного теоретически, но служит для того, чтобы привить определенное уважение к сложностям!
• Шаблоны корпоративной интеграции - это систематический взгляд на различные варианты дизайна, которые можно использовать для интеграции новых и устаревших компонентов.

Answer 2

Я в хвостовой части клиент-серверного приложения, которое я начал писать несколько недель назад. Я использовал WCF для .Net cient & server.

Но сервер также должен был подключиться к устройству в сети, которое понимало ASCII только через TCP / IP.

Вы абстрагировали биты связи?

Да. Похоже. Я имею в виду, я не уверен, что понимаю ваш вопрос на 100%. Для моего TCP-соединения со сторонним устройством я скрыл детали TCP-соединения и связи за классом, который я написал. Данное устройство преобразует команды ASCII в ИК-сигналы для управления такими вещами, как спутниковые антенны и DVD-плееры. Я абстрагировал связь TCP в класс, поэтому все, что нужно было сделать моему серверу, это сделать вызов вроде:

_irService.SendCommand(someAsciiCommand);

Какие классовые сущности вы придумали?

Они были основаны на моем домене. Ваш должен быть основан на том, что ваш домен. Я не уверен, что понимаю этот вопрос за этим. Ваш домен будет диктовать ваши объекты.

В моем домене я имел дело с серверным приложением, которое отвечало за планирование и проигрывание многоадресных трансляций по UDP с использованием VLC. Эти многоадресные трансляции должны были настраиваться во всех аспектах.

Когда я проанализировал домен, я пришел к модели, состоящей из Broadcasts, Channels, Devices и BroadcastProcesses (класс, отвечающий за запуск процесса vlc.exe и поддержание его жизненного цикла).

Домен мало повлиял на сетевые технологии. Я получил несколько дуплексных «сервисов» в WCF, которые позволили мне манипулировать доменом. Но выбор сети не был продиктован доменом. Мне нужно было TCP-соединение с двоичной сериализацией моих объектов, и я хотел двустороннюю связь с сервером, чтобы мои клиенты могли получать обновления в режиме реального времени через обратные вызовы. Эти параметры были доступны для меня независимо от того, как выглядел мой домен.