11.12.2006, 13:48 | #1 |
Участник
|
Когда нужно ставить свойство server на static методах
Здравствуйте Уважаемые Коллеги!
На сколько сложней системе обращатся к серверному статическому методу таблицы, чем просто к статическому? Т.е. почему методу статическому exist не ставить всегда server??? Мы же так должны экономить на передачах текстового запроса по сети?! (иммеется ввиду канал от клиента до AOS) |
|
11.12.2006, 14:07 | #2 |
Участник
|
Не текстового запроса.
Читайте Best Practice и документацию. Разработчики настоятельно рекомендуют уменьшать количество обращений (сеансов) клиент-сервер. Каждое обращение упаковывается в пакет (который сам по себе весит достаточно много). Кроме того, время на установление сеанса может быть достаточно большим. Т.е. лучше, если передаваемый между клиентом и сервером пакет данных будет побольше, нежели много маленьких пакетиков. |
|
11.12.2006, 14:57 | #3 |
Участник
|
Кстати, не в тему вопрос но все же.
Есть ли какое нибудь отличие если в статическом методе написано X++: Static void blablabla() { } X++: client server Static void blablabla2() { } |
|
11.12.2006, 15:04 | #4 |
Участник
|
Да.
Первый будет выполняться на сервере (если он есть) Второй будет выполняться там, откуда его вызвали. Читайте доку по ключевому слову Called from. |
|
11.12.2006, 15:14 | #5 |
Участник
|
Цитата:
Мне всегда казалось, что по умолчанию код static метода выполняется там же где и вызвавший его код (если конечно явно не указано server или client) А из ваших слов получается что static метод выполняется на сервере если не указано Client. Или я вообще все перепутал... |
|
11.12.2006, 15:14 | #6 |
Участник
|
Не совсем верно - первый будет зависить от свойства RunOn класса
__________________
Axapta v.3.0 sp5 kr2 |
|
11.12.2006, 15:21 | #7 |
Участник
|
Даже если метод статический?
Просто день открытий... |
|
11.12.2006, 15:33 | #8 |
Участник
|
В общем проверил на примере -
Получается что если ничего не указано, то исполнятеся там как указно в свойствах класса RunOn. А если в методе написано client server Static то тогда выполняется там же где выполняется вызвавший код. Теперь понятно почему кое где в коде встречалось client server Static |
|
11.12.2006, 15:45 | #9 |
Участник
|
__________________
Axapta v.3.0 sp5 kr2 |
|
11.12.2006, 16:04 | #10 |
Участник
|
Цитата:
Сообщение от mazzy
Не текстового запроса.
Читайте Best Practice и документацию. Разработчики настоятельно рекомендуют уменьшать количество обращений (сеансов) клиент-сервер. Каждое обращение упаковывается в пакет (который сам по себе весит достаточно много). Кроме того, время на установление сеанса может быть достаточно большим. Т.е. лучше, если передаваемый между клиентом и сервером пакет данных будет побольше, нежели много маленьких пакетиков. |
|
11.12.2006, 16:26 | #11 |
Участник
|
Цитата:
Сообщение от 6apcyk
Я собственно и хотел понять границу, когда надо переходить на серверный метод. Я еще раз упомяну: например на таблицах есть методы static exist(...), которые исполняются на клиенте, т.е передается запрос от клиента до сервера AOS, а потом судя по всему к базе. Поставив свойство server отпадает необходимость передавать запрос до сервера. Или я чего-то не понимаю ???
Мне кажется что если проверка идет по первичному ключу и на таблице включено кешировнаие то ключевое слово server не нужно. А так действитьельно кажется что должно бы быть оптимальнее с Server Непонятно только почему в стандартном коде написано без него. Наверно неспроста. |
|
11.12.2006, 17:39 | #12 |
Участник
|
Послушайте а почему я не могу одобрить сообщение AndyD ?
Новые правила одобрения ? Подряд нельзя одобрять ? Mazzy, если это не глюк то это неправильно Мне кажется нужно иметь возможность одобрять подряд одного и того же участника. Если это сделано как защита от накруток, то мне кажется все равно не спасет от недобросовестных участников. |
|
11.12.2006, 17:52 | #13 |
Axapta
|
Цитата:
Сообщение от Logger
Новые правила одобрения ? Подряд нельзя одобрять ?
Mazzy, если это не глюк то это неправильно Мне кажется нужно иметь возможность одобрять подряд одного и того же участника. Если это сделано как защита от накруток, то мне кажется все равно не спасет от недобросовестных участников. Т.е. придется еще кого-нить одного одобрить, прежде чем вернуться к AndyD. |
|
11.12.2006, 18:29 | #14 |
Участник
|
Цитата:
Сообщение от oip
Надо ли включать персональный рейтинг участинка?
Т.е. придется еще кого-нить одного одобрить, прежде чем вернуться к AndyD. И написал что не согласен. Думаю что неправильно так делать. Ну да ладно. Для AndyD и Mazzy репутацию вообще надо отключить. И так все ясно без рейтингов |
|
11.12.2006, 18:36 | #15 |
Участник
|
Цитата:
Это уже в планах на изменение. Пока продвижений правда нету |
|
11.12.2006, 19:13 | #16 |
Участник
|
Может тему поменяете, а то как-то на флуд похоже!!
Может у кого-нить есть идеи как это практически оценить??? |
|
13.12.2006, 12:32 | #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. |
|
13.12.2006, 13:02 | #18 |
Banned
|
Предложение не использовать свойство сервер в запросах к данным не имеет перспективы. По логике вещей, это имеет смысл делать в 3.0 только в случае 2-tier или Fat client. В противном случае запрос к БД все равно пойдет через сервер и вы заменяете явный вызов неявным. А в версии 4.0 есть только thin client.
|
|
13.12.2006, 13:02 | #19 |
Участник
|
Чтобы кеш совсем не мешал можно его временно на таблице отключить или в методе Exist поставить объявить локальную переменную InventTable и поставить
InventTable.disableCache(true); |
|
13.12.2006, 13:08 | #20 |
Участник
|
Цитата:
Сообщение от EVGL
Предложение не использовать свойство сервер в запросах к данным не имеет перспективы. По логике вещей, это имеет смысл делать в 3.0 только в случае 2-tier или Fat client. В противном случае запрос к БД все равно пойдет через сервер и вы заменяете явный вызов неявным. А в версии 4.0 есть только thin client.
Вообще то в 2-tier (подозреваю что и в Fat client тоже) модификаторы client и Server не имеют смысла - они ни на что не влияют. Все и так выполняется на клиенте, т.к. сервера приложений, на котором мог бы выполняться код - нет. Так что все что мы тут говорили имеет смысл только для thin client. (Про 4.0 не говорю - не знаю) |
|
|
|