Клиент-серверное приложение для работы с MySql

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

1. чем оличается web api от tsp сервера?
2. Как вообще организуется связь между клиентом и сервером?
   Я себе это примерно так представляю: клиент шлет название запроса + параметры запроса, а на сервере есть словарь с названиями запроса и соответствующих этому названию метод или делегат c sql запросом типо такого:
   

   C#
   1 2 3 4 5 var words = new Dictionary<string, MyFunc>() {     {"GetContainers", GetCon },     {"connect", GetCon }, };

   Ну и мы оттуда выбираем нужный выполняем sql запрос и отправляем обратно данные
3. Нужно ли конвертировать данные в json при таком подходе(если он вообще имеет место быть) или просто придумывать протокол и по нему слать пакеты?

Ну и надо наверное немного приложение описать. Создается оно для работы в компании.
Общая суть такая: клиент авторизуется, и работает то с бд, вносит удаляет редактирует данные, таких клиентов может быть много, так же приложение может быть доступно вне локальной сети.

0

У вас будет web api сервис, он будет связан с клиентом посредством http/https запроса, БД будет крутиться на сервере, какая там будет между ними прослойка не столь важно, можно использовать EF, можно прямое соединение не суть, сломать или пробросить что-то сводится к 0, т.к. для этого нужно взломать сам сервер на котором крутится ваш web api сервис. Что касаемо клиента, он может быть абсолютно любым: мобилка, десктоп, браузер и т.д. все общение сведется по сути к запросу и получению json в ответ

Добавлено через 3 минуты

Сообщение от firnen_dragon а на сервере есть словарь с названиями запроса и соответствующих этому названию метод или делегат c sql запросом типо такого

Нет, на сервере будет контроллер, в котором будут методы, например нужно вернуть всех студентов:
Добавлено через 2 минуты

Сообщение от firnen_dragon так же приложение может быть доступно вне локальной сети

Вне локальной сети, значит и клиент и сервер должны быть установлены на одной машине

1

Сообщение от Midian web api сервис

А в чем раздница то между tsp сервером и web api то просто организацию многопоточного сервера я понимаю, мы просто открываем отдельный поток на отдельного клиента и там работаем, а посомотрев web api как?

0

Сообщение от firnen_dragon таких клиентов может быть много

Все запросы на web api сервис выполняются в своем потоке, причем в браузере они все асинхронны, БД на сегодняшний день все умеют работать с множеством подключений

Добавлено через 3 минуты

Сообщение от firnen_dragon А в чем раздница то между tsp сервером и web api

TCP - что это?
Протокол управления передачей (англ. TCP - Transmission Control Protocol) обеспечивает надежную доставку данных. Сервис TCP так и называется: reliable byte stream (надежная передача потока байт). Этот протокол отвечает за доставку данных и сохранение порядка передаваемых сообщений.

Поток может быть большим. Как же в этом случае работает протокол? Допустим, вы скачиваете файл, который весит несколько Гб. В протоколе поток будет разбиваться на сегменты, и каждый из этих сегментов - отправляться получателю. На стороне получателя все части снова собираются.

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

Как это работает?

От отправителя к получателю "уходит" некий сегмент данных.

Приняв этот сегмент, получатель посылает отправителю подтверждение (ACK или Acknowledgement).

Данный процесс повторяется, пока передаются данные.

А вот что происходит, если при передаче произошла ошибка: сегмент теряется в сети, не доходит до получателя, и подтверждение не отправляется. Со стороны отправителя есть таймер, который задает время ожидания подтверждения. По истечении этого времени и за неимением ACK сегмент отправляется повторно.

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

В протоколе TCP также предусмотрена защита от дублирования и нарушения порядка сообщений (сообщения нумеруются).

Протокол HTTP
Мы видим HTTP в каждой ссылке: http://google.com/ и т.д.

Что это значит? HTTP - это протокол передачи гипертекста.

Грубо говоря, это тип разметки, которая добавляется в текстовые документы для определенного отображения текста. Например, в HTML используются теги. Так это выглядит в браузере, все знают.

В стеке протоколов HTTP находится на прикладном уровне.

Он использует протокол TCP и порт сервера 80 (для клиента порт генерируется операционной системой).

Режим работы HTTP - запрос-ответ: клиент посылает серверу запрос на передачу web-страницы, после чего сервер пересылает эту страницу клиенту. При этом нет жестко заданного формата пакетов: используется текстовый режим.

Скопировал в сети, по сути разница в протоколах, выше описано что представляет каждый из них

1

Сообщение от Midian HTTP - это протокол передачи гипертекста.

Спасибо, но зачем мне тогда HTTP, если мне передавать нужно то по сути только массивы объектов, которые на сколько я понял я могу передавать и без HTTP?

Добавлено через 2 минуты

Сообщение от Midian Все запросы на web api сервис выполняются в своем потоке

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

0

Сообщение от firnen_dragon Спасибо, но зачем мне тогда HTTP, если мне передавать нужно то по сути только массивы объектов, которые на сколько я понял я могу передавать и без HTTP?

Ну на этом построен web api, он использует http протокол и данные передавать придется в виде json, при желании можно передать массив байт в виде Base64 строки и на веб сервере преобразовать обратно в массив байт

Сообщение от firnen_dragon подключился клиент к примеру он авторизовался и работает себе пока поток соединения не будет завершен

а здесь вы создаете например HttpClient делаете запрос на сервер и ждете от него ответ, все это асинхронно и по выполнению запроса и получению ответа закрываете соединение

Добавлено через 3 минуты

Сообщение от Midian массивы объектов

ну что мешает десериализировать массив объектов из json?
Добавлено через 3 минуты
Почитайте что такое json, как с ним работать в .NET, почитайте про HttpClient, какие запросы бывают, как это работает и не будите задавать лишние вопросы, весь мир уже давно использует json, а не гоняет байты по TCP

Добавлено через 2 минуты

Сообщение от firnen_dragon что конкретному клиенту сейчас можно выдавать нужную информацию если я уже не помню авторизован он или нет

Если нужно общаться еще с клиентом в обратном направлении, уведомлять его о каком-то событии, почитайте про SignalR, это как-раз про ваш случай

1

Midian, Спасибо, бульмень чет начал понимать, пошел я читать про api

0

Сообщение от Midian ну что мешает десериализировать массив объектов из json?

учитывая что советуете работать с web api, там никто json не оперирует напрямую. Отправляются объекты и принимаются объекты. То что по факту он передается в виде json -- дело десятое.

0

Сообщение от Wolfdp Отправляются объекты и принимаются объекты

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

0

Midian, в таком случае применяют версионирование API, а не ручное чтение json'ов.

1

Сообщение от Midian Условно изменился список полей у объекта

Это в любом случае потянет изменение на клиентской стороне. То что я костылями могу увидить новые поля, не шибко помогает в вопросе "а что с ними делать".

0

Midian, Еще вопросик появился, разбираюсь в структуре net.core web api, и я не пойму где находится уровень логики, если мне допустим нужно что-то дополнительно вычислить или обработать, в контроллерах нельзя вроде как, в модели данных тоже, мне логику в сервисах писать нужно или как? Ну пример того что мне может понадобиться, подключение нейронки, шлю картинку она там обрабатывается потом по итогам длаем sql запрос и выплевываем клиенту то что получилось? Такое вообще логично писать в api?

0

Сообщение от firnen_dragon Midian, Еще вопросик появился

Не знаю можно ли ответить на вопрос другому, но тем не менее.

Сообщение от firnen_dragon я не пойму где находится уровень логики

Если клиент ожидает от web api обработанный результат, то реализуйте рабочий слой на стороне web api. Вариантов реализации несколько и рассмотрим простейший. Клиент прислал запрос на картинку; контроллер принял запрос и вызвал метод(ы) рабочего слоя (ну там класс какой нибудь или целый сервис); тот, в свою очередь, что-то сделал с данными (отправил в нейронку) и вернул результат; контроллер при необходимости преобразует результат и пуляет клиенту в качестве ответа.

Добавлено через 3 минуты

Сообщение от firnen_dragon а в web api как я пойму что конкретному клиенту сейчас можно выдавать нужную информацию если я уже не помню авторизован он или нет?

В заголовке запроса клиента к web api внедряют токен доступа. web api извлекает токен, проверяет его и если всё гуд, то обрабатывает запрос иначе выплёвывает ошибку и всё на этом.

1

Сообщение от Uswer реализуйте рабочий слой

Спасибо, а рабочий слой с контроллером связан явно? или как в wpf надо уведомлять о том что данные модели изменились через кастомное событие или INotifyPropertyChanged?

0

Сообщение от firnen_dragon Спасибо, а рабочий слой с контроллером связан явно? или как в wpf надо уведомлять о том что данные модели изменились через кастомное событие или INotifyPropertyChanged?

Вы сейчас про серверную часть или клиентскую?

0

Сообщение от Wolfdp Вы сейчас про серверную часть или клиентскую?

Серверную

0

Сообщение от firnen_dragon Еще вопросик появился, разбираюсь в структуре net.core web api, и я не пойму где находится уровень логики, если мне допустим нужно что-то дополнительно вычислить или обработать, в контроллерах нельзя вроде как, в модели данных тоже, мне логику в сервисах писать нужно или как? Ну пример того что мне может понадобиться, подключение нейронки, шлю картинку она там обрабатывается потом по итогам длаем sql запрос и выплевываем клиенту то что получилось? Такое вообще логично писать в api?

Можно прямо в web api, а можно вынести даже в отдельный сервис, о котором будет знать только web api и дергать его будет только он ожидая ответа и потом уже web api отдаст готовый результат клиенту, тут уж как угодно, если что-то жирное и требует ресурсов, то лучше вынести в отдельный контейнер docker и дергать его

Добавлено через 1 минуту

Сообщение от Usaga в таком случае применяют версионирование API, а не ручное чтение json'ов.

либо вариант еще использовать одну Core библиотеку, там где будут описаны все эти типы, ну это если приложение пишется на C#, а если там будут разные приложухи типа C++, Python, и т.д., тогда уже да, версионность спасет

1

firnen_dragon, MVVM применяется только в клиентской части, на серверной он не применим априори (внезапно на ней нет слоя View). Взаимодействие с WEB API оперирует понятиями Request-Response. На клиентской части обычно делают слой WebApiService, который инкапсулирует запросы на сервер. На самом сервисе API методы в идеале стоит делать тонкими, т.е. они должны вызывать внутрений сервис/репозитори/менеджер/провайдер с нужными параметрами и формировать ответ. Опционально валидировать входящие данные и креды.

В целом если по незнанию сделаете "толстый" api метод, то не смертельно. Просто это нереюзабельно и не покрывается тестами, скорее всего вам сейчас это не смертельно.

2