Добрый день. Вопрос большой, но пока интересует архитектура как это должно быть.
Итак, представьте что есть большое предприятие, с Интранет сетью, Active Directory c примерно 5000 активных пользователей. Внутри предприятия силами отдела разработки создано многочисленные как десктоп так и веб-приложения.
Необходимо создать некий сервис уведомлений, которым смогут пользоваться как разработчики со стороны своих приложений (т.е. интегрироваться с ним, и с помощью него отправлять уведомления) так и конечные пользователи, которые с помощью десктоп клиента или же веб-клиента получать уведомления адресованные им.
Одними из основных требований этих уведомлений, это то что они все должны где то хранится, а именно в базе данных, и каждое уведомление должно иметь своего получателя, прочитанность которого также должна фиксироваться в базе данных.
Я лишь ещё начинающий разработчик на C#, только только начинаю изучать это, потому я пока пытаюсь понять концепцию как это должно работать, считая что у этого сервиса в будущем должны быть различные дополнительные и обязательные функции (такие как контроль доступ к API, к возможности создания уведомления, его чтения и т.п.)
То сначала хочу понять как это на архитектурном уровне должно быть, чтобы потом могло легко допиливаться.
Прошу отнестись к моим высказываниям как совсем ещё начинающему разработчику.
Как я это вижу, допустим в качестве базы данных используется Oracle, хотя подразумеваю что нужно делать так, чтобы было без разницы какая база, что MySQL, MSSQL, Postgresql и т.п.
Т.к. подразумеваю, что база данных используется только как хранилище, только для CRUD (никакой бизнес логики в ней не должно быть, бизнес логику хочу поместить в приложение)
Модель базы данных понравилась здесь
www.vertabelo.com/blog/technical-articles/database...
Т.к. в ней есть понятие именно одного сообщения, и отдельных уведомлений с привязкой к сообщению для каждого пользователя, а также идеология групп подписок.
Т.е. по базе данных имею грубо говоря набор из 3х таблиц на первую простейшую реализацию, это message, message_recipient и user. С помощью которых уже можно создавать сообщения их уведомления с фактом прочтённости и со связью с получателем.
Сам механизм создания этих сообщения, я хочу поместить в отдельно живущее API в виде WebAPI на C#, которое по программе минимум будет иметь набор из несколько методов (или как то они подругому называются),с помощью которых можно создать сообщение и получить сообщение.
Т.е. разработчик будет отправлять на WebAPI некий HTTP запрос, где в параметрах как минимум укажет Текст сообщения, Идентификатор получателя/елей. Например:
ТЕКСТ СООБЩЕНИЯ: На вас назначена задача
ПОЛУЧАТЕЛЬ: "ivanov.aa","petrov.bb","sidorov.cc"
Таким образом в базе в таблице message создастся одна строка (т.к. одно сообщение) в таблице message_recipient 3 строки (т.к. 3 получателя) со связью на одну строку из таблицы message и по одной связи от каждой строки к таблице user соответственно по получателю
Таким образом будет на сервере приложений висеть в ожидание запросов некое WebAPI к которому будут обращаться разработчики со стороны своих приложений (тут конечно на будущее нужно будет как раз ещё как то реализовать разграничение прав доступ к API, т.е. вообще возможность создания сообщения, возможность кому отправлять сообщения (каким пользователям или сразу подписки с группой пользователей/подписчиков) но это уже потом
А далее получается нужен как минимум десктоп клиент, который будет висеть в трее пользователя и периодически опрашивать это же WebAPI на получение новых уведомлений с контекстом в виде текущего авторизованного в ОС пользователя. На что WebAPI должно выдать только те сообщения, которые доступны по связям текущему пользователю.
Пока не забегая далее вперёд, что можете сразу посоветовать, предупредить и по рекомендовать. Спасибо!
Простой
Простой
