WEB <-> Настройки <-> БД

← →
Polevi © (2009-07-01 14:28) [40]

если ты хочешь отобразить данные на объектную модель и в дальнейшем работать со списками и экземплярами связаных сущностей - тебе нужен ORM.. чтото вроде Hibernate

← →
sniknik © (2009-07-01 14:28) [41]

> Допустим, есть список устройств. .... Где ты будешь делать проверку, в JS?
да
> Тебе же нужен доступ к данным всех устройств, чтобы понять
да, и он там будет, ведь при таком списке тебе его придется "гнать" на клиента для организации выбора из уже существующих. и их номера там будут. раз говоришь будет их редактирование.
а можно сделать так, что при введении нового не посылать его номер, оставить это серверу (ну как автоинкремент в базах делается, только тут твой сервер будет его генерить и возвращать в ответ на запрос добавления, на случай его редактирования прямо после ввода)

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

> Вопрос не в том, чтобы распарсить (у меня точно такие же распарсенные параметры в TStringList хранятся),
> а в том, чтобы присвоить эти значения функциональному коду.
т.е. вот в этом?
Params.ParamByName(Name).Value := JSONObject[Name];
Params.ParamByName(Number).Value:= JSONObject[Number];
???
и том как в зависимости от типа операции разные запросы выполнять
типа
case JSONObject[action] of
0: .....;
1: .....;
и т.д.
???

← →
Пит (2009-07-01 14:43) [42]

>Sergey Masloff (01.07.09 14:05) [36]

концепцию понял. Но не понял удобства.

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

sniknik предлагает проверять параметры на клиенте (в браузере через JS-скрипт) - что мне кажется самым неправильным. Я проверяю в приложении на delphi. Ты предлагаешь проверять на стороне БД на его встроенном языке. Принципиально поставленные вопросы эти разные подходы не решают. Осуществляется контроль входящих парамметров, просто на разных этапах.

Я для этого уже класс написал. Его настройки я приводил, аля:

>Config.AddProperty("Name", "Название магазина", tpTextNotEmpty, "", 50, 20);

Если есть 7 настроек у сущности - значит 7 строчек настраивающих. И все, проверка автоматом, контроль автоматом, мне так даже больше нравится. Это пост номер [2] в этой ветке, решение описано.

Вопрос в связи с функциональными классами в программе.

> а зачем он хранит эту информацию ? web приложение stateless
> по умолчанию

я нигде не говорил, что у меня WEB-приложение! Если говорил - извиняюсь, это опечатка. У меня приложение, которое УПРАВЛЯЕТСЯ по WEB. А так в большинстве случаев запускается в виде сервиса и постоянно работает.

> если ты хочешь отобразить данные на объектную модель и в
> дальнейшем работать со списками и экземплярами связаных
> сущностей - тебе нужен ORM.. чтото вроде Hibernate

по ходу я погряз (((

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

Связь БД с WEB я реализовал, тут почти претензий нет. А вот как ты говоришь отобразить это на ООП модель - я запнулся. Есть мысли через RTTI присваивать значения свойствах объекта... Но как это все реально сделать... нет опыта, не хватает знаний.

← →
Пит (2009-07-01 14:57) [43]

> да, и он там будет, ведь при таком списке тебе его придется
> "гнать" на клиента для организации выбора из уже существующих.
> и их номера там будут. раз говоришь будет их редактирование.
>

элементарный пример. Сущностей (допустим, клиентов) много, выводятся они группами по 30 человек на странице, всего у нас 600 клиентов, значит это 20 страниц.
Ты предлагаешь в любом случае гнать в браузер информацию о всех 600 клиентах, но выводить на страницу только о 30?

А если для клиента в приложении построено некое дерево исходов, анализа. И по неким критериям оно не должно повторять дерево, построенное для другого клиента... Тоже JS?

Нет, я абсолютно убежден, что твой вариант неправильный. JS используют для контроля значений, но только как альтернативно-предварительный, чтобы не гонять данные по сети. Основная проверка - на стороне сервера, так всегда писали и писать я думаю будут.

> т.е. вот в этом?
> Params.ParamByName(Name).Value := JSONObject[Name];
> Params.ParamByName(Number).Value:= JSONObject[Number];
> ???
> и том как в зависимости от типа операции разные запросы
> выполнять
> типа
> case JSONObject[action] of
> 0: .....;
> 1: .....;
> и т.д.
> ???

не понял что ты хочешь сказать.

Переданные параметры доступны в виде TStringList"а, в формате "ParamName = ParamValue"

В посте номер [1] это четко показано:

if ParamList["action"] = "add" then

ну если очень хочется числами, то можно так:

if not TryStrToInt(ParamList["action"], iAction) then iAction := -1; case iAction of 0: 1: 2: ... end;

но в вебе лучше не делать так, гораздо нагляднее в URL-ах параметры "говорящие" наподобие "edit_client", "view_publication" и т.д.

← →
Пит (2009-07-01 15:07) [44]

почитал про ORM, про Hibernate. Ага, мне нужно такое, связь ООП и БД.

Но во-первых, разве такая реализация есть для Delphi?
Во-вторых, мне еще нужно связать это с WEB ((

Что сделать просто - связать WEB с БД, это мой класс TConfig, действие которого описано еще в посте [1]

Связывание ООП с БД оказывается называется ORM.
Связывание ООП с WEB не знаю как называется.

А мне нужно все эти три вещи связать...

← →
Пит (2009-07-01 15:09) [45]

> Связывание ООП с WEB не знаю как называется

например, для PHP в этих целях используют часть функционала Zend Framework.

Задача вырисовывается сложнейшая.. Но есть облегчение, что мне не нужно писать все возможные случаи связи, фактически самые простые...

← →
Sergey Masloff (2009-07-01 15:10) [46]

Пит (01.07.09 14:43) [42]

>Во-первых, фактически при таком способе ручной контроль параметров >перенесен из приложения на БД, правильно? Ну а что от этого меняется. >Проверять параметры в приложении или проверять в БД, объем кода от >этого не уменьшится и процесс разработки не сократится.
Уверяю что сократится. За последние 10 лет я "прошел" штук 10 технологий создания расширений веб-сервера каждая из которых объявляла предыдущую полным отстоем (и реально давала некоторые преимущества).
Кроме того за это же время я поменял 4 ОС на которых хостится веб-сервис, из четырех только на одной мог выполняться дельфийский код.
Вобщем с некоторых пор все что можно написать на стороне субд я пишу там.

Кстати из практики - код например на оракл связаный с обработкой данных получается статистически (счет строк порядка 10^6) минимум в 2 раза компактней по сравнению с дельфийским. При этом абсолютно портируемый - с солярки на аикс без единого чиха (даже с java проблемы были)

← →
Пит (2009-07-01 15:12) [47]

По ходу все таки мне никто не поможет... (( Технологий таких просто не существует. Только шанс встретить человека, который непосредстевенно решал поставленную задачу связи треугольника: WEB-функционал-БД и возможно имеет какие-то мысли.

← →
Пит (2009-07-01 15:20) [48]

> Уверяю что сократится. За последние 10 лет я "прошел" штук
> 10 технологий создания расширений веб-сервера каждая из
> которых объявляла предыдущую полным отстоем (и реально давала
> некоторые преимущества).
> Кроме того за это же время я поменял 4 ОС на которых хостится
> веб-сервис, из четырех только на одной мог выполняться дельфийский
> код.
> Вобщем с некоторых пор все что можно написать на стороне
> субд я пишу там.

ты все правильно пишешь. Сокращение кода идет думаю в частности из-за сильно упрощенного способа записи SQL выражений. То есть, то что в дельфи:

TQuery.Create
Query.SQL := UPDATE bla bla
Query.Exec;

то на внутреннем языке это будет одна строчка: UPDATE bla bla

Насчет хостингов - согласен с тобой.
Но еще раз, что я писал в [42] - у меня не WEB-приложении, я не говорил про WEB-приложение. У меня обычное приложение, которое просто управляется по WEB! Из-за преимуществ:

1) возможно удаленное управление
2) прозрачное управление в случае работы сервисом
3) не нужна клиентская программа (браузер сейчас везде)

← →
b z (2009-07-01 16:23) [49]

А в чем вопрос? :)
Как синхронизировать данные, т.е. сказать простой программе, что в конфигах произошли изменения и она должна как-то среагировать на это?
Ваше не веб-приложение и та простая программа, типа сервиса, это одна и таже программа/приложение или разные?

← →
Polevi © (2009-07-01 16:24) [50]

>Пит (01.07.09 15:12) [47]
Такие технологии существуют, но делфи тут не причем
Например связка Hibernate + Spring. (ORM и Dependency Injection frameworks)
Изначально созданы под Java, есть аналог для .Net (NHibernate и Spring.Net)
Делфи курит в стороне.
Но справедливости ради стоит заметить что время, необходимое на изучение подобных фрейморков часто бывает равно созданию собственных аналогов :)

← →
Пит (2009-07-01 16:25) [51]

> Ваше не веб-приложение и та простая программа, типа сервиса,
> это одна и таже программа/приложение или разные?

одна и таже. И приложение вовсе не простое ))

← →
Пит (2009-07-01 16:29) [52]

> Делфи курит в стороне

ну а что мне то делать? (((
Нет никаких идей по облегчению интеграции WEB-запросов и настройки функционального кода?

← →
b z (2009-07-01 16:47) [53]

> И приложение вовсе не простое ))
ошибся, "обычное" ...

На сколько я понимаю, вся задача все-таки в том как при изменении свойст конфига(ов), произошла адекватная реакция основного (обычного) процесса, я прав? а то вы как-то не среагировали на 2 мой вопрос.
Если прав, то ваши классы, ормы и т.п. фраймворки особо тут не помогут, хватит обычных датасетов, ну или если угодно вами типизированных, что особо ничего не меняет. И даже не понял при чем тут веб-нивеб, по моему нет разницы, каким образом идет управление. Мухи отдельно, котлеты отдельно. Похоже, что MVC тут может оказаться к месту. Это если я все-таки правильно понял. :)

← →
sniknik © (2009-07-01 16:59) [54]

> элементарный пример. Сущностей (допустим, клиентов) много ...
блин, ну нельзя же так резко в сторону "вилять", говорили про устройства, которых не так много скорее всего, а ты это все перекинул на клиентов которых больше.
хотя, во первых не страшно, у меня клиентов 5тыс (вернее ~4800), и в некоторых случаях передаются все. и ничего довольно быстро (около секунды) страничка со всем этим передается/отображается (это если они туда сразу в html вставляются, в случае получения подобного по ajax получается несколько дольше).
во вторых логика без загрузки всего тоже возможна, предлагал же ->
> а можно сделать так, что при введении нового не посылать его номер, оставить это серверу
> (ну как автоинкремент в базах делается, только тут твой сервер будет его генерить и возвращать
> в ответ на запрос добавления, на случай его редактирования прямо после ввода)
для клиентов это подойдет.
только вопрос - а ввод дублей человеком из-за того, что не видит большинства клиентов. не страшен?
или группы по какому то признаку так что ввод в эту группу не пересечется с остальными? т.е. дублей не будет.
тогда почему этот признак не вынести за пределы генерируемого номера? т.е. например группа 5 + 1-30 записей в ней, дали просмотрев номер 31 он гарантированно тогда будет уникальным, не пересечется с 31 из первой или другой группы.

← →
Пит (2009-07-01 17:13) [55]

sniknik, да вообще разговор лишний. Я не понимаю тебя, чем проверка на JS проще, чем проверка в коде дельфи.

Ну да это не принципиально. Принципиален вопрос связывания WEB с функционалом программы (пусть будет ООП) и с БД.

Polevi на мой взгляд хорошо понял задачу...

← →
Пит (2009-07-01 17:39) [56]

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

Но поскольку речь идет не о том - это не принципиально.

WEB с БД я связал легко, в очередной раз повторюсь, что это прекрасно делает класс, описанный еще в [1]

← →
sniknik © (2009-07-01 17:39) [57]

> Я не понимаю тебя, чем проверка на JS проще, чем проверка в коде дельфи.
> (пусть будет ООП)
пусть будет
когда ты пишешь на дельфи класс/форму ты разрываешь логику этой формы, того что в ней делается на 2 места? устанавливаешь поведение/значения ее компонентам из кода другой (основной) формы, или стараешься этого избежать и сделать класс "целостным"? потдерживаешь так сказать принципы ООП, инкапсуляцию данных (данные класса должны обрабатываться методами класса. по возможности) или нет?

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

как ответишь надеюсь поймешь.

> Polevi на мой взгляд хорошо понял задачу...
сказал больше умных, непонятных тебе слов, в процентах от общего сказанного количества? :о)

← →
Пит (2009-07-01 18:49) [58]

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

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

Но опять же проблема в сабже не в этом.

← →
sniknik © (2009-07-01 19:17) [59]

> Но опять же проблема в сабже не в этом.
а в чем же тогда?
мы уже похоже по всем пунктам цепочки прошлись, отсылка, прием, парсинг, сохранение в базу, и везде по отдельности говоришь проблем нет, и проблема в другом.
да, еще в самом начале предлагал компоненты для формирования html, которые могут прямо с веб через твой сервер в базу данные класть. тоже не подошли...

объяснил бы уж тогда, доступным языком, без использования сложных слов.

← →
Пит (2009-07-01 19:32) [60]

если честно - я просто не знаю как еще сказать.

Ты понимаешь, что проблемы исключительно связки WEB <-> БД нету, решение описано еще в посте [1]

Проблема в связке еще с функционалом кода. Я наверное повторяю эту фразу раз в 15-ый.

Прочти, пожалуйста, внимательно хотя бы мой пост [38], особенно в конце.

← →
sniknik © (2009-07-01 19:53) [61]

> если честно - я просто не знаю как еще сказать.
как? конкретно. на чем то реальном избегая общих фраз.

> Прочти, пожалуйста, внимательно хотя бы мой пост [38], особенно в конце.
вот это?
> В WEB интерфейсе клиент УДАЛЯЕТ некий экземпляр сущности. Провайдер TConfig понимает это и удаляет из БД соответствующую запись.
> Но как это изменение скажется в программе? Грубо говоря класс TSomebodyCollection, который хранит информацию о всех сущностях
> - как узнает об изменениях?
смотрим [41]
> типа
> case JSONObject[action] of
> 0: .....;
> 1: .....;
> и т.д.
> ???
допустим номер 3 у нас удаление. делаем ->
3: begin Command.ParamByName(ID).Value := JSONObject[ID]; Command.Execute; PostMessage(SelfProgramma, COMM_FROM_WEB, JSONObject[action], JSONObject[ID]); end;
все, программа "знает". по этому знанию может сделать чтото адекватное.

все просто, и опять без всяких классов.

← →
Piter © (2009-07-01 22:14) [62]

sniknik © (01.07.09 19:53) [61]

да, но я так понимаю ты говоришь об уведомлении, что что-то сделано. И я так понимаю, предлагаешь коду класса после получения такого обновления перечитать БД?

хм... ну в принципе надо подумать, наверное ты прав...

Я просто говорил о том, что идет не просто уведомление, что что-то произошло с записью ID, а о том что передаются непосредственные данные что произошло.

> предлагаешь коду класса после получения такого обновления перечитать БД?
это самое простое хотя и не единственно возможное. можно например по команде удаления вообще не удалять запись в базе, и не посылать уведомлений... а удалять непосредственно в том датасете который ее содержит и открыт, а в базе уж он сам...
или когда открыт делать одно, закрыт другое.

> а о том что передаются непосредственные данные что произошло.
не проблема, если нужно передавай непосредственно данные. собственно для удаления, ID записи собственно и будет полностью этими самыми данными.

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

sniknik © (01.07.09 22:55) [63]
не проблема, если нужно передавай непосредственно данные

как раз таки в этом и проблема, связывание запросов в WEB с изменениями в переменных программы. Вручную это делать геморно. Все данные приходят в текстовом виде, надо каждое обработать и присвоить свойствам функционального класса (например). Я и думаю о некой универсальности, которая по заданному прототипу будет вычислять данные из WEB запроса и присваивать значения нужным свойствам, через RTTI. Но как это сделать - проблемс... не придумал красивого решения.

sniknik © (01.07.09 22:55) [63]
и при таком упрощении скрипач (класс) не нужен.

да вполне удобный класс, но он связывает WEB-запрос с БД. Связывает очень прозрачно, быстр и легок в настройке.

Поэтому Polevi и предлагает связку двух технологий ORM и Spring, например. Одна связывает WEB с БД, другая связывает БД с ООП объектами в программе непосредственно. Или их интеграция может непосредственно связать WEB запрос и ООП.

Но это существует для java, но не для delphi.

> Все данные приходят в текстовом виде
сколько раз говорил, передавай в json-e, на стороне веба это практически родной обьект/массив/рекордсет, как составиш, на стороне дельфи через парсер тот же xml-документ (рекордсет, если ты конечно не навернешь туда древовидности)

> да вполне удобный класс, но он связывает WEB-запрос с БД. Связывает очень прозрачно, быстр и легок в настройке.
оно и видно, вопросов у тебя больше чем понимания, наверное изза удобст и легкости в настройке...

у меня же ушло 2 месяца от полного незнания hml и javascript до написания нормального сервлета примерно по такому же принципу работы что ты тут описываешь.
пользовался бы "удобными и легкими" но не на своем месте компонентами возился бы наверное до сих пор... а это уже год, и не закончил бы, к гадалке не ходи.

> предлагает связку двух технологий ORM и Spring, например. Одна связывает WEB с БД, другая связывает БД с ООП
что одно, что другое сомнительное удовольствие... ИМХО.
пытался сделать хоть что-то одно, например разработать объекты для работы с базой? попробуй. упаришься. и ничего кроме ограничений для работы с базой, ухудшения алгоритмов и увеличения ресурсоемкости не добьешься.
вот сделаешь ты например объекты для работы с учебной базой. предметы там. ученики и т.д. будешь долго дописывать/отлаживать добавляя сущности вылезшие по ходу работы, добавишь туда добавление, удаление и т.д. а после окажется нужен будет отчет, и никак его кроме как запросом хитрым с какими нибудь джойнами не сделать (а это уже не объект, это уже объединение черт знает чего. в концепцию не "ложится"), а вот запросом запросто, т.е. либо в обход твоих классов, либо добавлять туда "хитрозатесанные" составные обьекты которые на самом деле не объекты. ти т.д. и т.п.
ну ладно все добавил все решил, отладил, после смотриш на это дело со стороны и с ужасом понимаешь все это получилось УЗКО специализированным, только для учебной базы, а вот использовать для накладных или бугалтерии/любого другого это не получится, даже больше того, поменяй учебную базу на от другого факультета, и это уже тоже не подойдет. надо чуть ли не с нуля переписывать...
а ведь это будет даже не основной код, это будет надстройка по работе с базой, избыточная работа единственное оправдание которой в том что "потом это пригодится, счаз помучаюсь, напишу, потом не придется.". и вот фиг тебе ЕЩЕ КАК придется.

а потом, после того как попробуешь реализовать одно, вот тогда пробуй объединить 2 технологии... но тогда думаю откажешься. поумнеешь и скажешь "а нафига это вообще надо?" (вот тогда и вспомни что тебе это же самое изначально говорили)

> Но это существует для java, но не для delphi.
какая разница? это же не компоненты, это технология, там наверняка тоже надо "классы-объекты в базе" описывать. ну разве, что там уже есть такие предопределенные предки с вшитым коннектом к базе, который автоматически подсоединяется если есть обращение к описанному объекту потомку. в общем не думаю, что там задача сильно облегчена по сравнению с дельфей.

← →
Пит (2009-07-02 11:06) [66]

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

> Пит (02.07.2009 11:06:06) [66]

Странно, что еще не побили.

> Ты по всему очевидно считаешь, что разбираешься в данном вопросе намного лучше меня
ну... у меня есть одно завершенное приложение (сервлет) сделанное по такому принципу, а сколько у тебя?
если скажешь, что 2 или хотя бы 1 с половиной, тогда я радостью возьму на заметку гуру к которому можно обратиться в случае чего...

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

← →
Пит (2009-07-02 13:44) [69]

ну пиписьками я тем более меряться не хочу.

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

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

> sniknik ©

Мне все таки кажется, что полность полагаться исключительно на проверки введенных данных JavaScript-ом несколько ненадежно. Лучше всего дублировать проверки и на клиенте (для удобства) и на стороне сервера.

← →
Пит (2009-07-02 14:05) [71]

> Нет, я абсолютно убежден, что твой вариант неправильный.
> JS используют для контроля значений, но только как альтернативно-
> предварительный, чтобы не гонять данные по сети. Основная
> проверка - на стороне сервера, так всегда писали и писать
> я думаю будут.

> что полность полагаться исключительно на проверки введенных данных JavaScript-ом несколько ненадежно.
полагаться исключительно только на... и не предлагалось, предлагалось проверять там, на сервере считать присланные данные верными, но эксепты все таки не забывать.
большой разницы в том сам ты возбудишь этот ексепт по дублированной (ака лишней) проверки на сервере, или это придет от базы при записи нет.

или имеются ввиду проверки диапазонов чисел и подобное, но это уже логика разнесенная на 2 места, только дополнительные неудобства. сейчас у тебя один диапазон, завтра другой, и исправлять надо не в одном месте, а по всей цепочке. а если где забыл там будет "непонятка"(глюк).

WEB <-> Настройки <-> БД Найти похожие ветки