Добрый день, захотелось попробовать слепить небольшую информационную систему по типу клиент-сервер.
Установил indy 10 для написания клиента и сервера, дальше с моим скудным знанием сетевых архитектур, я не знаю куда двигаться дальше..
Подскажите, как организовать соединение между клиентом и сервером?
Я так понимаю на сервере должны лежать: подключение к БД и различные query компоненты, а с клиента это все дело вызывается и передается в датасеты?
Клиент-серверное приложение
Модератор: Модераторы
Вы описываете трехуровневую архитектуру, здесь надо хорошо подумать, надо ли это для небольшой ИС. Может быть будет достаточно двухуровневой(Клиент-Сервер БД)?
У меня сейчас так построено, с одного экзешника подключаются с клиента (БД на сервер БД)WAYFARER писал(а):Вы описываете трехуровневую архитектуру, здесь надо хорошо подумать, надо ли это для небольшой ИС. Может быть будет достаточно двухуровневой(Клиент-Сервер БД)?
Хотелось бы трехзвонку попробовать...
При всем моем разочарование в идеях " тотального внедрения Веб- интерфейсов " для частичной замены старой "Клиент-серверной архитектуры" эта технология подходит как нельзя лучше.san7667 писал(а):Добрый день, захотелось попробовать слепить небольшую информационную систему по типу клиент-сервер.
Установил indy 10 для написания клиента и сервера, дальше с моим скудным знанием сетевых архитектур, я не знаю куда двигаться дальше..
Подскажите, как организовать соединение между клиентом и сервером?
Я так понимаю на сервере должны лежать: подключение к БД и различные query компоненты, а с клиента это все дело вызывается и передается в датасеты?
Пишем простой веб-сервер с применением того-же indy 10, а в клиент засовываем банальный html-вьювер ( можно даже без браузерного движка ) и все ! Никаких "танцев с бубном" вокруг сокетов сетевых протоколов и прочего "лоу-тека 20-го века". Прелесть веб-технологии в том что это практически "терминальный доступ" к серверу, а это значит что все вероятные коллизии и блокировки обрабатываются только одной программой а доступ к БД надежно "инкапсулирован" и отделен от любого "клиентского-произвола" .
Зы
Почему я пишу о "частичной замене" ? Потому что "клиентский код" писать все-же придется но на "темной стороне сервера". То есть после авторизации сервер по сути запускает "виртуальный клиент" с которым и будет работать "удаленный пользователь" (в прочем как и условно "локальный ") с помощью "псевдо терминала " с веб-интерфейсом.
Зы Зы
А если интересны причины моего "разочарования" то она очень проста, дело в том что современные Веб- интерфейсы просто чудовищно громоздки и часто фактически запуская "полноценный-целевой-софт-на-JS" по сути губят саму суть идей лёгкости и прозрачности "Веб-пространства" .(ничего не имею против умеренного использования скриптов но это ИМХО должно быть просто вспомогательной функцией типа "часиков" или легкой анимации на веб странице )
Последний раз редактировалось Alex2013 21.08.2023 12:16:32, всего редактировалось 1 раз.
Проект будет закрытый или открытый?san7667 писал(а):Добрый день, захотелось попробовать слепить небольшую информационную систему по типу клиент-сервер.
Установил indy 10 для написания клиента и сервера, дальше с моим скудным знанием сетевых архитектур, я не знаю куда двигаться дальше..
Подскажите, как организовать соединение между клиентом и сервером?
Если закрытый, то приведите аналогичный пример существующей рабочей системы, которая может выступить в качестве прототипа для вашей, чтобы понимать не обобщенно, а конкретное ТЗ на систему.
Если открытый, то максимально подробно опишите, что и как будет с пользовательской точки зрения, хорошо бы завести себе github, хотяб для элементов системы чтобы можно было понимать ход движения и давать конкретные советы и направления.
Сейчас все очень расплывчато, а отправлять просто читать литературу тоже не хочется...
Но библию все же надо посоветовать. Разработка Web-служб средствами Delphi
Вот тут очень хорошо в главе 2 про сокеты:magnet:?xt=urn:btih:121FDF7B85C5A6772F2E16492DF502731AC5C480&tr=http%3A%2F%2Fbt3.t-ru.org%2Fann%3Fmagnet&dn=Мастер%20программ%20-%20Дарахвелидзе%20П.%20Г.%2C%20Марков%20Е.%20П.%20-%20Разработка%20Web-служб%20средствами%20Delphi%20%5B2003%2C%20PDF%2C%20RUS%5D
Добавлено спустя 12 минут 58 секунд:magnet:?xt=urn:btih:6C65BBDC8FFC582C98D5E0B156F83CA5360CB35B&tr=http%3A%2F%2Fbt4.t-ru.org%2Fann%3Fmagnet&dn=Григорьев%20А.Б.%20-%20О%20чём%20не%20пишут%20в%20книгах%20по%20Delphi%20%5B2008%2C%20PDF%2C%20RUS%5D
Про архитектуры и миграцию БЛ мне понравилось у автора Indy, вот статья в переводе Где наша бизнес-логика, сынок?Alex2013 писал(а): Прелесть веб-технологии в том что это практически "терминальный доступ" к серверу, а это значит что все вероятные коллизии и блокировки обрабатываются только одной программой а доступ к БД надежно "инкапсулирован" и отделен от любого "клиентского-произвола" .
delphius, спасибо за книжки. Мне не лишние 
Всегда пожалуйстаSharfik писал(а):спасибо за книжки. Мне не лишние
Тогда, чтобы добить, максимально подробно про winsock тут, правда примеры на с
Талмуд еще тот, но раньше умели хорошо писать...
Я в эти дебри полез, когда с smtp разбирался с нативными сокетами...что-то глубоко полезmagnet:?xt=urn:btih:6BA396BFDDBCF20FF14A8A9ED13512E0AA2E3F63&tr=http%3A%2F%2Fbt4.t-ru.org%2Fann%3Fmagnet&dn=Мастер-класс%20-%20Джонс%20Э.%2C%20Оланд%20Д.%20-%20Программирование%20в%20сетях%20Microsoft%20Windows%20%5B2002%2C%20PDF%2C%20RUS%5D
От меня тоже спасибо ! ( Хотя по моему многое описанное в книгах и особенно в статье избыточно по отношению к проектам на Лазарусе ( обычно это малые (до сотни пользователей и БД максимум до 1-4-х гигов (чисто "конторский софт")) или средние (несколько сотен пользователей (небольшая торговая площадка ) и БД примерно до 10 гигов) проекты ) ) Решать такие задачи с помощью многозвеньевой архитектуры и отдельного сервера БД ИМХО явно избыточный "оверкилл").
У ТСа в первом сообщении ключевое слово "попробовать", при уже существующей рабочей клиент серверной схеме, так что я думаю, что в учебных целях все будет оправдано.Alex2013 писал(а):Решать такие задачи с помощью многозвеньевой архитектуры и отдельного сервера БД ИМХО явно избыточный "оверкилл"
Но послушаем, что он сам скажет
Там же тоже много всякого интересного есть, например connection pooling
Вот я и решил подойти со стороны готового решения, и взял с англоязычного форума пример приложения клиент-сервер. Уже несколько месяцев вместо того чтобы спать разгребаю почему не работает то одно, то другое. Единственный плюс - за меня выстроенная архитектура деления на потоки. В остальном автор накосячил, у него все работало потому что тайминги были большие. И сообщение коротки были. А как попробовал сделать серию команд для работы с БД, все стало грустно. Вспоминаю что когда то читал про сокеты.. но вот вопрос заполнения буфера сокета у меня проблемный. Никак не могу понять как эту сволочь очистить когда я хочу.Alex2013 писал(а):От меня тоже спасибо ! ( Хотя по моему многое описанное в книгах и особенно в статье избыточно по отношению к проектам на Лазарусе ( обычно это малые (до сотни пользователей и БД максимум до 1-4-х гигов (чисто "конторский софт")) или средние (несколько сотен пользователей (небольшая торговая площадка ) и БД примерно до 10 гигов) проекты ) ) Решать такие задачи с помощью многозвеньевой архитектуры и отдельного сервера БД ИМХО явно избыточный "оверкилл").
А используется в примере что-то на базе этого набора?Sharfik писал(а):Вот я и решил подойти со стороны готового решения
А, перечитал, двухзвенка...
Добавлено спустя 1 час 33 минуты 18 секунд:
Рабочий вариант, но с двух сторон есть узкие места, с одной стороны веб сервер как таковой (на сервере), а с другой стороны (на клиенте) вьюер.Alex2013 писал(а):Пишем простой веб-сервер с применением того-же indy 10 а клиент засовываем банальный html-вьювер
Если опираться на общепринятые на данный момент способы реализации, то похожая, но более универсальная схема трехзвенки будет представлять собой Сервер БД -> Мост --> REST API -> http + json -> Клиент.
Можно спокойно реализовать на чистом fpc, например с помощью SQLDBRestBrige
Примеры тут и тут
Upd. Все примеры работают, проверил, но все надо допиливать, как всегда
Клиент в такой схеме можно реализовать любым способом, так как будет использоваться обычный json over http от rest api
Если нужен более полный контроль и оперативный двухсторонний обмен по постоянному соединению, а клиенты будут не только в локальной сети, но и удаленные, то можно реализовать с помощью вебсокетов, в транке fpc уже есть модули