|
|
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
softwarerНапример, форма ввода данных состоит из нескольких страниц (закладок); если параметры введены с ошибкой, клиентское приложение должно переключиться на соответствующую закладку, поставить курсор на соответствующее поле ввода и написать что-нибудь типа "дата должна быть не раньше 01.01.2000". У нас например каждая страница с данными обрабатывается отдельно. При открытии многостаничной формы из базы насасывается информация о доступности и обязательности полей. Соответственно доступные поля становятся с белым а обязательные с желтым фоном. При сохранении формы скрипт пробегает по настройкам переключая страницы и выставляя фокус на поля которые не были заполнены с предложением ввести данные. Потом если все норматьно открывается транзакция и данные начинают постранично сохраняться в базе, в этот момент срабатывают проверки сервера, при получении сообщеня об ошибке фокус переходит на ошибочную страницу, транзакция откатывается и выдается сообщение об ошибке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 14:35 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
А по поводу основного вопроса я считаю "Все что можно перенести на сервер, должно быть там" ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 14:39 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
EstetsУ нас например каждая страница с данными обрабатывается отдельно. То есть бизнес-логика, серверная часть зависит от интерфейса? Если завтра клиент скажет "вот эти данные, пожалуйста, заузьте и поместите на одной странице, а вот здесь, наоборот, сделайте побольше места и раскидайте на две" - вы сядете менять серверный код? Estets При открытии многостаничной формы из базы насасывается информация о доступности и обязательности полей. Соответственно доступные поля становятся с белым а обязательные с желтым фоном. То есть часть проверок таки делается на клиенте. Но именно поэтому я и привел пример менее стандартной проверки. Разумеется, есть несколько стандартных задач проверки, но кроме этого есть и уникальные, применимые именно к этим данным. С точки зрения интерфейса логика их обработки абсолютно та же - спозиционироваться в точку, где можно исправить некорректные данные. Estetsпри получении сообщеня об ошибке фокус переходит на ошибочную страницу, То есть, насколько я понимаю, уже на страницу, а не на конкретный элемент. И цена этого - структура бизнес-логики, жестко завязанная на структуру интерфейса, что само по себе плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 15:29 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
softwarer Cat2msn13. Зря не соглашаетесь. Окончательную проверку должен делать сервер. А клиент - только первая линия обороны. Безусловно. И чем это "зря не соглашаетесь"? Я бы сказал, клиент - первая и основная линия обороны, сервер - в основном резервная. Проверки на сервере защищают в первую очередь от ошибок программиста, от сопровождающих, лезущих в базу мимо сервера итп. Вообще говоря в нормальной ситуации эти проверки срабатывать не должны, исключая те самые отдельные проверки, которые делать на клиенте плохо и не удобно. В принципе может быть поставлен вопрос о последующем отключении проверок на сервере в целях быстродействия. На клиенте плохо и не удобно делать любые проверки, связанные с состоянием БД в части "быстро" меняющихся данными. Например логично на клиенте закешировать справочник валют, и там пресекать дублирование, ( в купе с кнопкой "перечитать кеш справочников" ). А вот дублирование скажем материалов есть смысл проверять только на сервере. Пока я проверяю на клиенте, ситуация на сервере уже опять могла измениться. Поэтому для таких проверок сервер - единственная линия обороны. Конечно все, что можно, отсечь на клиенте, нужно делать там, но и то в две "подлинии обороны". Когда выполнять проверку Дата начала <= Дата окончания.? Очевидно, только когда пользователь нажмет OK или что-то подобное, сигнализируя об окончании работы со всем документом, формой в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 16:06 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
tygraВсе, что можно, должно обрабатываться на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 17:05 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
tygraВсе, что можно, должно обрабатываться на сервере. Я б сказал так: все, для чего приспособлен сервер, должно обрабатываться на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 17:06 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
ModelRНа клиенте плохо и не удобно делать любые проверки, связанные с состоянием БД в части "быстро" меняющихся данными. Я нисколько не оспариваю наличие проверок, которые не стоит делать на клиенте - наоборот, изначально и специально их упомянул. Состав и примеры - можно обсуждать, но стоит ли? ModelRКонечно все, что можно, отсечь на клиенте, нужно делать там, но и то в две "подлинии обороны". Когда выполнять проверку Дата начала <= Дата окончания.? Очевидно, только когда пользователь нажмет OK или что-то подобное, сигнализируя об окончании работы со всем документом, формой в целом. Безусловно. С моей точки зрения, идеальное место такой проверки - TDataSet.BeforePost (если знакомы с Delphi). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 17:38 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
Проблема эта актуальна когда сервер и клиент пишутся на разных языках. А вот для pl/sql все пишется универсально а размещается в зависимости от ситуации. В большинстве случаев - на сервере, но при ОЧЕНЬ большом числе пользователей сервер БД надо макс разгружать и приходится все тащить на клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 17:40 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
модПроблема эта актуальна когда сервер и клиент пишутся на разных языках. Никакой разницы. модА вот для pl/sql все пишется универсально а размещается в зависимости от ситуации.... Странно, но почему-то несколько раз, когда в форуме Oracle поднимались вопросы "как сделать", оказывалось, что "клиентский pl/sql" не поддерживает более чем обычных возможностей "pl/sql серверного". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 17:46 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
softwarer ModelRНа клиенте плохо и не удобно делать любые проверки, связанные с состоянием БД в части "быстро" меняющихся данными. Я нисколько не оспариваю наличие проверок, которые не стоит делать на клиенте - наоборот, изначально и специально их упомянул. Состав и примеры - можно обсуждать, но стоит ли? Это про то, что на клиентская линия обороны - основная. Какая же она основная если дырявая? От этих эпитетов одни недоразeмения:). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 18:10 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
ModelRЭто про то, что на клиентская линия обороны - основная. Какая же она основная если дырявая? Если верить книгам про войну, то за линию фронта чуть ли не каждую ночь ходили разведгруппы и прочие партизаны. Что не мешало иметь ей быть "основной" :)) ModelRОт этих эпитетов одни недоразeмения:). Факт :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 18:12 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
softwarer wrote: > ModelR > Это про то, что на клиентская линия обороны - основная. Какая же она > основная если дырявая? > > > Если верить книгам про войну, то за линию фронта чуть ли не каждую ночь > ходили разведгруппы и прочие партизаны. Что не мешало иметь ей быть > "основной" :)) да с какой такой стати клиент - основная линия обороны? клиент тогда-уж - охранник при входе в банк, который не пустит унутрь какого-нить бомжа бухого... Вот есть у меня документ "Реестр квитанций". при создании на сервере проверяется, что заполнены такие-то поля, сумма и количество квитанций - положительные и прочая лабуда. Для создания есть проца. Ага, могу и на клиенте проверить - всё ли ОК. А теперь появился документ "Выписка банка"... и вот, при подписи выписки надо, чтобы по каждой строке выписки создавался "реестр квитанций"... И что? теперь мне надо учить банковскую выписку тому, что должно быть заполнено в реестре? Ить проверки то на клиенте? Или проца по созданию реестра (которой плевать, откель мы реестр создаем - с клиента, из другого документа) проверит всё необходимо и в случае ошибки даст отлуп? Типа, сосредоточим управление в одном узле, а не размажем его по системе? -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 11:52 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
softwarer модПроблема эта актуальна когда сервер и клиент пишутся на разных языках. Никакой разницы. перетащите t/sql на клиента или VB на сервер :) softwarerСтранно, но почему-то несколько раз, когда в форуме Oracle поднимались вопросы "как сделать", оказывалось, что "клиентский pl/sql" не поддерживает более чем обычных возможностей "pl/sql серверного". в новых версиях разницы нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 12:20 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
модПроблема эта актуальна когда сервер и клиент пишутся на разных языках. Сервер использует язык Delphi ??? Не видел я что-то такого :)) модА вот для pl/sql все пишется универсально а размещается в зависимости от ситуации. В большинстве случаев - на сервере, но при ОЧЕНЬ большом числе пользователей сервер БД надо макс разгружать и приходится все тащить на клиента. Угу - пару тройку 10-миллионных табличек заселектить по одной, а потом вместе слить и подсчитать группировки, и все это на клиенте А может сервер у вас хиленький - вообще то сервера для того, чтобы клиентов разгружать. а не наоборот :) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 14:20 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
модперетащите t/sql на клиента или VB на сервер Если это важно - пишите на java или на C#. Впрочем, учитывая что проверки надо делать и там, и там, перетаскивать ничего не нужно. модв новых версиях разницы нет Насколько я в курсе, последняя новая версия появилась довольно давно, а обсуждения были довольно недавно. Проясните? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 14:21 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
так и я об этом java еще можно перетащить на сервер в ХП (только в оракле) а C# уже нет а транзакт-скл на клиента вообще не тащится т.е. надо все разделить до программирования что не есть хорошо я на различия в pl/sql не натыкался возможно что-то и есть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 15:45 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
модтак и я об этом Я - как раз не об этом, наоборот. По мне это не играет роли, но чем доказывать это - проще показать, что при желании "единый код" делается далеко не только на PL/SQL модjava еще можно перетащить на сервер в ХП (только в оракле) Да неужто? Думаю, ASCRUS возразит.... мода C# уже нет Да неужто? мода транзакт-скл на клиента вообще не тащится Да и тащить его незачем. Честно говоря, никогда не понимал желания "все делать на одном языке", что клиента писать на PL/SQL, что сервера на C#. модт.е. надо все разделить до программирования что не есть хорошо Ээ... То есть предлагаете подход "сначала делаем, потом думаем"? модя на различия в pl/sql не натыкался возможно что-то и есть Мне вспоминается возврат ref cursor из ХП, динамический SQL... Я мягко говоря не специалист в формсах, но люди спотыкались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 17:22 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
lockyда с какой такой стати клиент - основная линия обороны? клиент тогда-уж - охранник при входе в банк, который не пустит унутрь какого-нить бомжа бухого... Предлагаю таки завершить спор о терминологии. Охранник - так охранник. lockyИ что? теперь мне надо учить банковскую выписку тому, что должно быть заполнено в реестре? Ить проверки то на клиенте? А где написано "проверки только на клиенте"? После того, как сто раз повторено строго обратное? Раз уж Вы привели такой пример, давайте смотреть. Есть таблица, типа Код: plaintext 1. 2. 3. И чему Вы собираетесь учить свою банковскую выписку? Скривили в ней - сервер Вам как разработчику сообщит об этом. А вот для ввода этой таблицы на клиенте, мягко говоря, стоит использовать другой механизм проверок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 17:28 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
softwarer модjava еще можно перетащить на сервер в ХП (только в оракле) Да неужто? Думаю, ASCRUS возразит.... Лучше не буду возражать - java в ASA никто особо не пользуется, в BOL на хранение обьектов в таблицах обьявлено depricated, не удивлюсь что в приближающейся 10-ке вообще java вынесут и из extended sp - туда ей и дорога с сервера, WatcomSQL рулит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 17:42 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
Согласен с softwarer - проверки вводимых данных должны быть и на клиенте и на сервере. Причем в обычных ситуациях проверки на сервере работают только для подстраховки. Они только для особых ситуаций - устаревание информации на клиенте (как возможная штатная ситуация), разработка другого клиента к этой же базе, ошибка/недоработка программиста клиента (как внештатные ситуации), и т.п. Вот отключать серверные проверки с целью увеличения быстродействия я бы все-таки не стал - чревато... Если только для какого-нибудь совсем простого случая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2005, 18:22 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
Архитектура клиент-сервер: сервер СУБД: SQL + ХП на языке(ах) 1,2,3 клиент на языке(ах) 4,5,6 если языки совпадают - это дает большие преимущества действительно можно сначала делать а потом думать что где размещать причем в разных реализациях одной и той же системы по разному можно конечно и на разных языках, но тода думать надо сразу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 09:36 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
Тут наверное еще стоит упомянуть такую ситуацию при размещении всей логики на сервере, как незасимость БД от клиентской части. Простой пример - есть БД и клиентская часть. На клиентской части только примитивные проверки (можно сказать штатные), на БД реализованы все проверки и логика. Руководство по неким причинам решило переписать клиентскую часть на другой среде программирования (любые причины - устарела старая, потребовались новые возможности и т.д.) или же решило написать еще одну клиентскую часть (для реализации того же веб-интерфейса). Думаю не стоит обьяснять, что при полной реализации логики в БД переписать или написать еще одного клиента - это элементарный вопрос рисования формочек, которые через вызовы ХП получают и сохраняют данные, ничего не зная о структуре БД, реализации логики и прочего. С другой стороны реализация какой либо логики на клиенте, ответственной за целостность БД и расчеты уже приведет к тому, что придется существенно попотеть, чтобы переписать клиентскую часть. Наглядный пример - ФС (без разницы какие - Access, FoxPro, Clipper, ...) - перенос таких приложений в другую среду программирования - это большое и сложное дело, где частенько в коде тесно переплетены и завязаны управление интерфейсом, бизнес-логика и расчеты и клубок этот распутать чрезвычайно сложно, легче написать ТЗ и реализовать задачу с полного нуля. P.S. Кстати в моей практике реально бывали случаи, когда клиенты просто надували губы и говорили - не хотим клиента на Delphi, хотим на C#, на что в принципе имея всю логику на борту БД я всегда спокойно мог ответить "Да без проблем, доплачивайте и клиент на C# будет ваш". А если им еще и веб-интерфейс хотелось, так вообще понятие клиентского приложения так же переносилось на ASA, которая умеет спокойно работать как полноценный веб-сервер и веб-интерфейс спокойно и легко реализуется там же в БД - на ХП языка WatcomSQL, который к примеру ничем не уступает по возможностям работы с вебом тому же PHP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 10:06 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
модАрхитектура клиент-сервер: сервер СУБД: SQL + ХП на языке(ах) 1,2,3 клиент на языке(ах) 4,5,6 если языки совпадают - это дает большие преимущества действительно можно сначала делать а потом думать что где размещать причем в разных реализациях одной и той же системы по разному можно конечно и на разных языках, но тода думать надо сразу :) Не понял - о чем это? Какие совпадающие языки? Вы о чем? Ыыыыыыы -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 10:45 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
модесли языки совпадают - это дает большие преимущества Стандартная песня. Увы, наскучила. Только в рамках этого форума за последние пару лет полномасштабно обсуждалось раза три, последний раз - в свете топика "C# в Yukon". Предлагаю зафиксировать несогласие в этом и остановиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 11:47 |
|
||
|
Серверная и клиентская логика - где граница?
|
|||
|---|---|---|---|
|
#18+
ASCRUSТут наверное еще стоит упомянуть такую ситуацию при размещении всей логики на сервере, как незасимость БД от клиентской части. Это довольно неоднозначный вопрос. При этом склонна появляться как раз зависимость от клиентской части, только другого рода. При реализации "максимально тонкого" клиента на сервере часто прорезаются ХП, относящиеся не столько к бизнес-логике, сколько к логике интерфейса, и соответственно изменение интерфейса (даже в рамках одного и того же клиентского инструмента) начинает требовать изменений на сервере. ASCRUSP.S. Кстати в моей практике реально бывали случаи, когда клиенты просто надували губы и говорили - не хотим клиента на Delphi, хотим на C#, на что в принципе имея всю логику на борту БД я всегда спокойно мог ответить "Да без проблем, доплачивайте и клиент на C# будет ваш". Согласитесь, что этот ответ годится как в том, так и в другом случае :) ASCRUSА если им еще и веб-интерфейс хотелось, То я пока что еще ни разу не видел веб-интерфейса серьезного приложения, который назвал бы "приемлимым". Я здесь имею в виду, назовем так, html-интерфейс, а не тяжелую артиллерию типа апплетов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2005, 12:01 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33439102&tid=1545498]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
421ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 750ms |

| 0 / 0 |
