![]() |
#1 |
Участник
|
Когда нужно ставить свойство server на static методах
Здравствуйте Уважаемые Коллеги!
На сколько сложней системе обращатся к серверному статическому методу таблицы, чем просто к статическому? Т.е. почему методу статическому exist не ставить всегда server??? Мы же так должны экономить на передачах текстового запроса по сети?! (иммеется ввиду канал от клиента до AOS) |
|
![]() |
#2 |
Участник
|
Не текстового запроса.
Читайте Best Practice и документацию. Разработчики настоятельно рекомендуют уменьшать количество обращений (сеансов) клиент-сервер. Каждое обращение упаковывается в пакет (который сам по себе весит достаточно много). Кроме того, время на установление сеанса может быть достаточно большим. Т.е. лучше, если передаваемый между клиентом и сервером пакет данных будет побольше, нежели много маленьких пакетиков. |
|
![]() |
#3 |
Участник
|
Кстати, не в тему вопрос но все же.
Есть ли какое нибудь отличие если в статическом методе написано X++: Static void blablabla() { } X++: client server Static void blablabla2() { } |
|
![]() |
#4 |
Участник
|
Да.
Первый будет выполняться на сервере (если он есть) Второй будет выполняться там, откуда его вызвали. Читайте доку по ключевому слову Called from. |
|
![]() |
#5 |
Участник
|
![]() Цитата:
Мне всегда казалось, что по умолчанию код static метода выполняется там же где и вызвавший его код (если конечно явно не указано server или client) А из ваших слов получается что static метод выполняется на сервере если не указано Client. Или я вообще все перепутал... |
|
![]() |
#6 |
Участник
|
Не совсем верно - первый будет зависить от свойства RunOn класса
__________________
Axapta v.3.0 sp5 kr2 |
|
![]() |
#7 |
Участник
|
Даже если метод статический?
Просто день открытий... |
|
![]() |
#8 |
Участник
|
В общем проверил на примере -
Получается что если ничего не указано, то исполнятеся там как указно в свойствах класса RunOn. А если в методе написано client server Static то тогда выполняется там же где выполняется вызвавший код. Теперь понятно почему кое где в коде встречалось client server Static |
|
![]() |
#9 |
Участник
|
__________________
Axapta v.3.0 sp5 kr2 |
|
![]() |
#10 |
Участник
|
Цитата:
Сообщение от mazzy
![]() Не текстового запроса.
Читайте Best Practice и документацию. Разработчики настоятельно рекомендуют уменьшать количество обращений (сеансов) клиент-сервер. Каждое обращение упаковывается в пакет (который сам по себе весит достаточно много). Кроме того, время на установление сеанса может быть достаточно большим. Т.е. лучше, если передаваемый между клиентом и сервером пакет данных будет побольше, нежели много маленьких пакетиков. ![]() |
|
![]() |
#11 |
Участник
|
Цитата:
Сообщение от 6apcyk
![]() Я собственно и хотел понять границу, когда надо переходить на серверный метод. Я еще раз упомяну: например на таблицах есть методы static exist(...), которые исполняются на клиенте, т.е передается запрос от клиента до сервера AOS, а потом судя по всему к базе. Поставив свойство server отпадает необходимость передавать запрос до сервера. Или я чего-то не понимаю
![]() Мне кажется что если проверка идет по первичному ключу и на таблице включено кешировнаие то ключевое слово server не нужно. А так действитьельно кажется что должно бы быть оптимальнее с Server Непонятно только почему в стандартном коде написано без него. Наверно неспроста. |
|
![]() |
#12 |
Участник
|
Послушайте а почему я не могу одобрить сообщение AndyD ?
Новые правила одобрения ? Подряд нельзя одобрять ? Mazzy, если это не глюк то это неправильно ![]() Мне кажется нужно иметь возможность одобрять подряд одного и того же участника. Если это сделано как защита от накруток, то мне кажется все равно не спасет от недобросовестных участников. |
|
![]() |
#13 |
Axapta
|
Цитата:
Сообщение от Logger
![]() Новые правила одобрения ? Подряд нельзя одобрять ?
Mazzy, если это не глюк то это неправильно ![]() Мне кажется нужно иметь возможность одобрять подряд одного и того же участника. Если это сделано как защита от накруток, то мне кажется все равно не спасет от недобросовестных участников. Т.е. придется еще кого-нить одного одобрить, прежде чем вернуться к AndyD. ![]() |
|
![]() |
#14 |
Участник
|
Цитата:
Сообщение от oip
![]() Надо ли включать персональный рейтинг участинка?
Т.е. придется еще кого-нить одного одобрить, прежде чем вернуться к AndyD. ![]() И написал что не согласен. Думаю что неправильно так делать. Ну да ладно. Для AndyD и Mazzy репутацию вообще надо отключить. И так все ясно без рейтингов ![]() |
|
![]() |
#15 |
Участник
|
Цитата:
Это уже в планах на изменение. Пока продвижений правда нету |
|
![]() |
#16 |
Участник
|
Может тему поменяете, а то как-то на флуд похоже!!
![]() Может у кого-нить есть идеи как это практически оценить??? |
|
![]() |
#17 |
Участник
|
Тестирование метода InventTable::exist(...)
Решил протестировать всетаки.
Вот какая запускалась метода, такой большой перебор по номенклатуре для того, чтобы не использовать кэш. X++: static void Test_InventTableExist(Args _args) { int runTimes; int counterItemId, time, itemIdLength = 6; ItemId curItemId; ; for(runTimes = 0; runTimes < 20; runTimes++) { time = WinAPI::getTickCount(); for(counterItemId = 1; counterItemId < 99999; counterItemId++) { curItemId = int2Str(counterItemId); curItemId = strrep("0", itemIdLength - strLen(curItemId)) + curItemId; InventTable::exist(curItemId); } info(strFmt("%1", WinAPI::getTickCount() - time)); } } server static <-->static 144047 <-->152800 145289 <-->150006 146871 <-->150556 143727 <-->149615 149415 <-->150036 152629 <-->203893 158198 <-->255257 147482 <-->254897 143737 <-->232815 149244 <-->229189 174641 <-->226956 164527 <-->222520 175032 <-->217683 176173 <-->230852 171246 <-->237452 158649 <-->251481 182011 <-->247827 181631 <-->204254 177556 <-->224062 177876 <-->237311 Результаты не ахти, но покрайнеймере не говорят в пользу не использовать свойство server. |
|
![]() |
#18 |
Banned
|
Предложение не использовать свойство сервер в запросах к данным не имеет перспективы. По логике вещей, это имеет смысл делать в 3.0 только в случае 2-tier или Fat client. В противном случае запрос к БД все равно пойдет через сервер и вы заменяете явный вызов неявным. А в версии 4.0 есть только thin client.
|
|
![]() |
#19 |
Участник
|
Чтобы кеш совсем не мешал можно его временно на таблице отключить или в методе Exist поставить объявить локальную переменную InventTable и поставить
InventTable.disableCache(true); |
|
![]() |
#20 |
Участник
|
Цитата:
Сообщение от EVGL
![]() Предложение не использовать свойство сервер в запросах к данным не имеет перспективы. По логике вещей, это имеет смысл делать в 3.0 только в случае 2-tier или Fat client. В противном случае запрос к БД все равно пойдет через сервер и вы заменяете явный вызов неявным. А в версии 4.0 есть только thin client.
Вообще то в 2-tier (подозреваю что и в Fat client тоже) модификаторы client и Server не имеют смысла - они ни на что не влияют. Все и так выполняется на клиенте, т.к. сервера приложений, на котором мог бы выполняться код - нет. Так что все что мы тут говорили имеет смысл только для thin client. (Про 4.0 не говорю - не знаю) |
|
|
|