LINUX.ORG.RU

Вопрос по архитектуре приложения

 


0

1

Добрый день.

Есть приложение, которое состоит из, по сути, 3-ех основных частей: 1. Пользователи 2. Устройства 3. Очередь команд

Допустим, сущности «пользователи» и «устройства» общаются с ПО по TCP. Сущность «Очередь команд» некий объект, который хранит в себе команды полученные от «пользователя», которые потом передаются в «устройство», «устройство» выполняет команду и результат помещает обратно в «Очередь» из которой потом «пользователь» забирает результат.

Попробовал изобразить это в виду UML диаграммы: https://ibb.co/rxGwdGj

Возможно что-то изобразил не правильно, поэтому вот краткое описание:

class ServerUser : public IServerUser
{
private:
	IUser usersList;
	IQueue *queue;		// при создании объекта ServerUser передает указатель на объект Queue
public:
	void newUser()
	{
		user = new User(this); // в объект User передаем ссылку на объект сервера
		userList.append(user);
	}
	void sendCommand(int deviceId, string cmd)
	{
		queue->sendCommand(deviceId, cmd);
	}
	void gotAnswer(int userId, int string answer)
	{
		userList[userId]->gotAnswer(answer);
	}
}

class User : public IUser
{
private:
	IServerUser *server;
public:
	void gotAnswer(answer)
	{
		// ...
	}
	void eventSendCommand()
	{
		// получено событие от пользователя, что нужно отправить команду
		server->sendCommand(deviceId, cmd);
	}
}

class Queue : public IQueue
{
private:
	IServerUser *serverUser;
	IServerDevice *serverDevice;
public:
	void sendCommand(int deviceId, string cmd)
	{
		serverDevice->sendCOmmand(deviceId, cmd);
	}
	// аналогично для получения ответа
}

// классы ServerDevice и Device реализованы по подобию реализации ServerUser и User

Сейчас для того чтобы отправить команду, ответ на команду нужно вызывать метод сервера, который в свою очередь будет вызывать метод Queue. Если объект Queue в объекты User, Device, то тогда будет получаться меньше писанины, но так, по идее, нарушается слабая связанность классов User, Device и Queue. Какой вариант более предпочтителен?

Ответ на: комментарий от anonymous

Ну это не ответ на вопрос. Вопрос был не в очереди сообщений и как ее организовать, а в связи между объектами.

hell_wood
() автор топика

но так, по идее, нарушается слабая связанность классов User, Device и Queue

У тебя и так внутри реализации очереди связь с IServerUser и IServerDevice.

Либо не мучайся и делай всё напрямую, либо делай нормальную изоляцию, когда у очереди есть только абстрактные подписчики, а уже User и Device реализуют интерфейс подписчика.

В существующем варианте, где у очереди обязательно только один пользователь, её вообще можно внутрь пользователя упаковать.

monk ★★★★★
()

Казалось бы, причем здесь акторы?

При работе в рамках Модели Акторов у вас User-ы и Device были бы акторами и вы могли бы распространять ссылки между ними как вам было бы удобно. Нужны User-ам ссылки на Device — пожалуйста, передавайте их User-ам и храните внутри User-ов. Нужно Device после выполнения команды отдавать ответ конкретному User-у, так пусть внутри команды хранится ссылка на User-а, которому нужно ответить.

А вся кухня по поддержке очередей сообщений пусть разруливается акторным фреймворком. Вы сможете сосредоточиться на реализации бизнес-логики.

eao197 ★★★★★
()

тебе нужен pub/sub

например редис, чтоб быстро всосать.

а если это прям девайсы, то mqtt, например.

Rastafarra ★★★★
()
Ответ на: комментарий от Rastafarra

Наверное не стоило тут называть класс Очередью. Его смысл в другом, команды это как одна из его задач. Грубо говоря, он хранит ссылки «пользователь» - «устройство». Каждый пользователь должен быть связан с одним устройством. В класс прослойке (тут он зовется Queue) есть инфа о связке пользователь-устройство.

hell_wood
() автор топика
Ответ на: комментарий от hell_wood

Грубо говоря, он хранит ссылки «пользователь» - «устройство»

Тогда нет ничего плохого в его сильной связности с этими классами.

monk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.