Перейти к содержанию
Fire Monkey от А до Я

Какие компоненты использовать в клиент-сервере


Рекомендуемые сообщения

Проконсультируйте. Есть желание создать небольшое клиент-серверное приложение. Серверная часть на компе. Клиентская на телефоне. Подскажите какие компоненты использовать? в vcl есть ServerSocket и ClientSocket

при создании мультидевайс приложения эти компоненты не доступны.

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

Ссылка на комментарий
  • Ответов 53
  • Создана
  • Последний ответ

Топ авторов темы

Я бы порекомендовал использовать idHTTP на клиенте, а на сервере - mormot HTTPAPIServer. На худой конец - на сервере тоже idHTTPServer.

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

Ссылка на комментарий

Я бы порекомендовал использовать idHTTP на клиенте, а на сервере - mormot HTTPAPIServer. На худой конец - на сервере тоже idHTTPServer.

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

HTTPAPIServer нет такого компонента.

возможно использовать на сервере TidHTTPServer

а на клиенте просто  TidHTTP?

и еще...... смысл такой. на стационарном компе (сервере) запущена серверная часть. она связывается с БД считывает от туда данные и должна передавать клиенту. Клиент мобильное приложение на телефоне Android

Ссылка на комментарий

 

HTTPAPIServer нет такого компонента.

возможно использовать на сервере TidHTTPServer

 

и еще...... смысл такой. на стационарном компе (сервере) запущена серверная часть. она связывается с БД считывает от туда данные и должна передавать клиенту. Клиент мобильное приложение на телефоне Android

 

Тогда тем более не стоит возиться с TCP. HTTP вам в руки :)

HTTP API Server - этот компонент не входит в состав Delphi, а является частью ORM mormot - http://synopse.info/fossil/wiki/Synopse+OpenSource

Не хотите ставить - используйте Indy и там и сям :)

Ссылка на комментарий

че-то технологию попутали как топикстартер так и остальные...

ваши "TCP.." это все 3 уровневая технология, причем в разы сложнее реализации самой "клиент-сервер"

возьмите любую базу MySql или Sqllite да и вперед, куда проще...никаких собственных серверов(велосипедов)

Ссылка на комментарий

rustam_d - предлагаете делать двузвенку "мобильный толстый клиент - СУБД"? Имхо, не стоит.

от задачи зависит конечно, но толстого клиента убил Devart.com еще в 90-х...,

а если не умеете писать хранимые процедуры...то вам точно не пойдет "толстый" клиент )

теоретически в реализации и задумке, андроид и иос не отличаются от виндовс приложений,

а в них ВСЕ толстые )), толстые чтоб вы знали, это "не зависимый интерфейс", веб дефакто тонкий...

а вот дроид и иос увольте ), можно тонкий и на них...но не для этого они )

есть магаз же, сбегал обновился, а винде его не было ранее...да и щас мало кто юзает

Изменено пользователем rustam_d
Ссылка на комментарий

че-то технологию попутали как топикстартер так и остальные...

ваши "TCP.." это все 3 уровневая технология, причем в разы сложнее реализации самой "клиент-сервер"

возьмите любую базу MySql или Sqllite да и вперед, куда проще...никаких собственных серверов(велосипедов)

чаво ?

Ссылка на комментарий

Вообще задумка была такая: на компе запущена прога-сервер. она связывается с БД любой. будь то SQlite или access. считывает данные из базы.

а клиент на телефоне. на телефон данные формируются в   TStringList TMemoryStrem или что то подобное и передаются через компоненты для работы с сетью.

Мне просто хочется освоить даннуую технологию, но знаний пока не хватает.

значит можно организовать передачу данных если на сервере и клиенте использовать HTTP и передавать данные GET и POST запросами?

Изменено пользователем AndroidHalfNoob
Ссылка на комментарий

пишешь tcp\http сервер, который общается с любой базой. выносишь апи наружу для клиентов, которые шлют запросы через тот-же tcp\http

я вот уже не в первой теме вижу желание некоторых людей завязывать логику на клиенте. зачем ?

клиент(а тем более мобильный) должен быть по-максимуму универсальным

имхо конечно...

Ссылка на комментарий

пишешь tcp\http сервер, который общается с любой базой. выносишь апи наружу для клиентов, которые шлют запросы через тот-же tcp\http

я вот уже не в первой теме вижу желание некоторых людей завязывать логику на клиенте. зачем ?

клиент(а тем более мобильный) должен быть по-максимуму универсальным

имхо конечно...

есть пример какого нибудь простого кода для передачи данных?

Ссылка на комментарий

 

rustam_d - предлагаете делать двузвенку "мобильный толстый клиент - СУБД"? Имхо, не стоит.

от задачи зависит конечно, но толстого клиента убил Devart.com еще в 90-х...,

а если не умеете писать хранимые процедуры...то вам точно не пойдет "толстый" клиент )

теоретически в реализации и задумке, андроид и иос не отличаются от виндовс приложений,

а в них ВСЕ толстые )), толстые чтоб вы знали, это "не зависимый интерфейс", веб дефакто тонкий...

а вот дроид и иос увольте ), можно тонкий и на них...но не для этого они )

есть магаз же, сбегал обновился, а винде его не было ранее...да и щас мало кто юзает

 

Даже если и умеете писать - толстые клиенты это зло. Именно сервер должен заниматься не только хранением, но и иметь бОльшую часть функционала по обработке данных. Это значительно упрощает всяческие обновления, нововведения и устранения глюков. Попробуйте выпустить мобильного толстого клиента с какой-нибудь незамеченной ошибкой, которая приводит к нестыковке данных в БД, а потом заставить всех пользователей обновить приложение - да половина не сделает этого в разумные сроки. И будете вставлять костыли в свои хранимки.

В Windows далеко не все клиенты толсты, у вас устаревшие сведения.

"Есть магаз" - я вот принципиально не обновляю из магаза некоторые приложения: часть из них убили отвратительным переводом на Material Design, а часть от версии к версии все больше кушает память, что для моего телефона уже непозволительно.

И чтобы вы знали - "толстость" клиента к "независимому интерфейсу" отношения не имеет. Если я правильно вас понял, то под независимым интерфейсом вы понимаете MVC. А "толстость" определяется тем, где производится основная работа с данными: обработка, преобразование, вылавливание ошибок и т.п. Если на клиенте - он толстый, если на сервере - то тонкий.

Ссылка на комментарий

 

 

rustam_d - предлагаете делать двузвенку "мобильный толстый клиент - СУБД"? Имхо, не стоит.

от задачи зависит конечно, но толстого клиента убил Devart.com еще в 90-х...,

а если не умеете писать хранимые процедуры...то вам точно не пойдет "толстый" клиент )

теоретически в реализации и задумке, андроид и иос не отличаются от виндовс приложений,

а в них ВСЕ толстые )), толстые чтоб вы знали, это "не зависимый интерфейс", веб дефакто тонкий...

а вот дроид и иос увольте ), можно тонкий и на них...но не для этого они )

есть магаз же, сбегал обновился, а винде его не было ранее...да и щас мало кто юзает

 

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

у меня в MSSQL именно так, весь функционал по обработке данных в хранимых процедурах, которые правлю в БД,

а вот отображение на клиенте в интерфейсе...

Ссылка на комментарий

Не должен клиент напрямую коннектиться к базе. Должна быть прослойка. Пофигу: тонкая или толстая. Если бизнес логика предполагает миграцию на другую бд - толстая, есои нет - бизнес в пакетах\процедурах. Нельзя с клиента напрямую к бд идти. Должен быть rest-сервис. Пофигу - tcp\http, на дельфях он или на джаве, на питоне, на асп.нете... Клиент должен идти через прослойку. Имхо

Ссылка на комментарий

Не должен клиент напрямую коннектиться к базе. Должна быть прослойка. Пофигу: тонкая или толстая. Если бизнес логика предполагает миграцию на другую бд - толстая, есои нет - бизнес в пакетах\процедурах. Нельзя с клиента напрямую к бд идти. Должен быть rest-сервис. Пофигу - tcp\http, на дельфях он или на джаве, на питоне, на асп.нете... Клиент должен идти через прослойку. Имхо

"Не должен, должен..." существенные аргументы...норм стиль.

Миграция бизнеса? )) чувствуется стиль java или asp прогеров, кто пишет app servera на голом sql )).

Обычно такие программеры используют MSSQL и ORACLE в качестве FoxPro видал массу примеров...

Порой диву даешься или шок, когда видишь, что дорогущий сервер БД используется на 0.0001%, а остальное делает "свой" сервер...

Конечно 3 уровневая схема тож норм подход, но по времени и простоте разработки в проигрыше клиент-серверу, от задачи же все зависит...

а пушки для воробьев у нас за здрасьте...

Ссылка на комментарий

ты вообще о чем ? что значит "app servera на голом sql" ? это вообще как ?

"

Обычно такие программеры используют MSSQL и ORACLE в качестве FoxPro видал массу примеров...

Порой диву даешься или шок, когда видишь, что дорогущий сервер БД используется на 0.0001%, а остальное делает "свой" сервер...

"

ты вообще понимаешь о чем я пишу ?

я не говорю использовать субд только как хранилище. 

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

но ! прослойка между клиентом и субд быть должна ! не стоит клиентам напрямую общаться с субд.

если миграция предполагается, либо возможна работа с разными бд в одном контексте, то ТЕМ БОЛЕЕ должно быть промежуточное звено !

зачем в клиент пихать логику ? ладно, не логику. зачем в клиент пихать провайдеры доступа к субд ? на разным платформах кучу нюансов.

да и не один адекватный сисадмин не пробрасывает наружу порты доступа к бд(если это только не шарашка с 10-15 сотрудниками).

блин . ну детский сад йомайо. о чем разговор то... элементарные вещи обсуждаем...

Ссылка на комментарий

ты вообще о чем ? что значит "app servera на голом sql" ? это вообще как ?

ты вообще понимаешь о чем я пишу ?

 

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

3-звенка с 90-х еще, как, зачем, и для чего это то и есть элементарно, многие професс проекты так и реализованы

вам то про топик писали...что вполне живуч. 3-х звенка пишите 2 программы вместо 1-й и радуетесь...

время то походу вагоны для проектов

 

бизнес логика должна(по-моему) реализовываться на уровне субд

странно но об этом и писал вроде...а вы про миграцию пакетов, процедур...структура БД это только 15% бизнес логики, остальное в хранимках

 
ладно, не логику. зачем в клиент пихать провайдеры доступа к субд ? на разным платформах кучу нюансов

не стоит бросаться словами в области в которой ноль...а то тешите деварт...нечего их смешить...

 

да и не один адекватный сисадмин не пробрасывает наружу порты доступа к бд(если это только не шарашка с 10-15 сотрудниками).

а как вы настраиваете БД на виртуальных хостах? через http ? )) мсье знает толк в изв...

 

 
 
Ссылка на комментарий

тема перешла в раздел спора:) и ни кто не заметил мое сообщение.....

кто может дать кусок кода в котором реализована отправка данных через компонент HTTP.

Ссылка на комментарий

кто может дать кусок кода в котором реализована отправка данных через компонент HTTP.

ваш вопрос относиться чисто к Делфи...это не совсем по адресу...

такие вещи писали с 90-х...во времена королевства делфи )

вот если то что работает в делфи не работает в фмх тогда другое дело

Ссылка на комментарий

 

кто может дать кусок кода в котором реализована отправка данных через компонент HTTP.

ваш вопрос относиться чисто к Делфи...это не совсем по адресу...

такие вещи писали с 90-х...во времена королевства делфи )

вот если то что работает в делфи не работает в фмх тогда другое дело

 

я пишу программу на Delphi XE8

Ссылка на комментарий

 

 

кто может дать кусок кода в котором реализована отправка данных через компонент HTTP.

ваш вопрос относиться чисто к Делфи...это не совсем по адресу...

такие вещи писали с 90-х...во времена королевства делфи )

вот если то что работает в делфи не работает в фмх тогда другое дело

 

я пишу программу на Delphi XE8

 

да хоть на Delphi 6...никакой разницы...почитайте лучше разницу между VCL и FMX (этот сайт для последнего)...

Ссылка на комментарий

Давайте уже действительно прекратим холивары.

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

 

Я вот, как ни странно, для Indy10 не нашел примеров организации работы idHTTPServer. С клиентом там все понятно, хотя его работа и вызывает нарекания, к примеру - на кой нужно возбуждать исключение на ответ сервера 400 - непонятно.

А вот по серверу - полный ноль, а если мне память не изменяет - сигнатуры событий у индейцев в 10 отличаются от 9.

Сам я не использую Indy на сервере, предпочитаю Mormot, он гораздо быстрее и легковеснее.

 

Поделитесь с ТС...

Ссылка на комментарий

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу

×
×
  • Создать...