Здравствуйте, AndrewVK, Вы писали:
IT>>Это само собой. Просто stateful это хорошая питательная среда для выращивания крупномасштабных глюков. Так что кривые руки + stateful... просто страшно подумать что может получиться.
AVK>Кто бы спорил. Создание серверов приложений было и пока что есть одна из самых сложных задач.
Усложнять — просто, упрощать — сложно (с) Закон Мейера
Сложными её делают кривые ручки.
Если нам не помогут, то мы тоже никого не пощадим.
хъ
H_D>Ну не скажи... B+Дерево пишется на коленке за 2 часа первый раз, а второй (я думаю) я напишу и того быстрее..
На ящик пива готов спорить, что твоя реализация и рядом не будет валяться с стльной.
H_D> а если я его (вот извращение-то) напишу на MC++ в неменеджед классах с менеджед оберткой — оно вообще рулить будет.
За 2 часа? Ох уж этот юношеский максимализм.
H_D>А само исполнение запросов.. ну, могу тебе сказать, что в объектных системах SQL как таковой не нужен при запросах к бизнес данным. SQL нужен при запросе к хранилищу, а при запросе к бизнес данным все просто — у нас нет агрегирующих ыункций — раз и мы возвращаем объекты целиком — два (а иначе — это уже не ОО)
Т.е. эти агрегаты сами из воздуха появляются?
хъ
IT>>Возьми хотя бы кеширование веб-страниц в веб-браузере. При повторном запросе никуда ходить не надо, HTML формировать не надо, даже самого интернета не надо. Страница лежит в кеше и всегда готова к отображению. H_D>Ага... теперь смотрим по Ctrl+F5 ту же страницу.... упс, а она уже совсем другая незадача, однако...
Здравствуйте, Hacker_Delphi, Вы писали:
H_D>Здравствуйте, IT, Вы писали:
IT>>Я боюсь, что ты не верно истолковал мои слова. Когда я говорю о целостности БД, я имею ввиду только проверку связей и допустимость значений. Т.е. FK и констрейнты. О тригерах я ничего не говорил. H_D>К несчастью, FK не всегда применимы... H_D>у меня в системе они не применимы вообще, потому, что объект на который ссылаемся может совсем в разных таблицах лежать... и ничего с этим не поделаешь...
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, IT, Вы писали:
IT>>Чушь полная. Все проверки которые можно сделать средствами БД нужно делать средствами БД.
AVK>А не передергиваешь? Нет, понятно что reference constraint нужно делать средствами БД, но городить навороченные триггеры точно не стоит. Вот у меня под боком живой пример. Обращение к одной из вьюх примерно в 200 раз медленнее прямого доступа к таблице. При этом вьюха отличается всего лишь проверками. Сервер приложений такую проверку сделает со свистом.
С++ порождает код в несколько раз быстрее дотнетовского. Все летает со свистом. Однако же ты используешь дотнет, потому что он проще и на нем легче писать грамотный код. Тут фактически, тот же выбор.
Здравствуйте, AndrewVK, Вы писали:
TK>>Это уже не состояние, а демагогия.
AVK>А по мне так самое натуральное состояние. Иначе непонятно что же тогда вобще состояние.
Вот может ты и дашь определение как автор этого термина
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
IT>>Дать ему уникальный guid при создании.
AVK>Это уже решение проблемы средствами бизнес-логики, о чем я и говорил.
А ты можешь провести чёткую грань?
IT>>Откуда сделан такой вывод?
AVK>А вот предложения ТК и твои лучшим образом это подтвердили. И он и ты постоянно предлагаете мне править прикладной код для решения задачи управления.
Я тебе предлагаю не изобретать велосипеды.
IT>> Пока я вижу, что ты не теми средствами решаешь поставленную перед тобой задачу.
AVK>Я? Я пока что ничего не решаю. Я собственно и решения то не предлагал никакого.
То что ни решения, ни одного конкретного примера — это я заметил Всё больше намёки о существовании некоего невероятно крутого сервера приложений
IT>> переписывать бизнес-правила тебе не придётся. Только перерисовывать
AVK>Это уже детали. Впрочем в данном конкретном случае может оно и прокатит. Не зальешь дистрибутив на сервер?
Надо будет пошукать.
IT>>Ты делаешь свою систему как коробочный продукт или на заказ/для своей конторы?
AVK>Черт его знает. Пока точно не известно. Вероятность того что это будет коробка не нулевая. Даже если это будет внутренний продукт совершенно точно его будут пользовать внедрюки в различных филиалах.
Так может тогда стоит делать всё по нормальному? Для подобных задач существуют решения, но они все жутко дорогие. Причём в чём поинт таких цен я не понимаю
AVK>Спасибо что разъяснил . А бизтолк не катит, его стоимость для конечного решения будет дороже того за что можно наш продукт продать .
Козлы они. Смотрят на Ремеди и Оракл и цены задирают. Удержать такие цены на подобные системы можно только вступив с остальными производителями в сговор.
IT>>Это тут при чём? Или у стэйтфул программистов есть секретарши, которым они надиктовывают свой код?
AVK>Нет, у них есть сервер приложений.
Сервер у всех есть.
IT>>Код то всё равно писать
AVK>Код управления состояниями?
Я тебе уже доложил. Код о котором ты говоришь вообще писать не надо, его можно рисовать.
IT>>Ничего оно не ограничивает. А совсем наоборот. Благодаря простоте реализации stateless оставляет больше времени, чтобы бегать по этим просторам.
AVK>Ну да, вроде хранения состояния в БД всегда, даже если его хранить то надо десяток секунд.
Если пользователь нажал Save и перешёл к другой операции, то хранить надо даже пол секунды. Документ, появившийся в системе не должен из неё исчезать бесследно. Хотя... учитывая твои слова о специфики российского бизнеса всё возможно
AVK>>>Хороши усилия — после каждого запроса скидывать состояние в БД
IT>>Подожди, подожди. А разве у тебя состояние объектов может не соответствовать их состоянию в БД?
AVK>В незакрытой транзакции? Может конечно, иначе ради чего огород городить?
Т.е. мы опять приходим к тому, что если кончилась батарейка, то тётя Маша, нажавшая за секунду до этого Save, сама дура. Найс. Андрей, ты понимаешь что это не серьёзно? О том, к чему может привести такая "оптимизация", дети BL-девелоперов проходят в детском саде.
AVK>А кто спорит. Просто необходимость непрерывно переписывать бизнес-логику начисления приводит к возрастанию фактора простоты написания этой бизнес-логики. Ты думаешь почему у 1С предприятия практичеси полное доминирование на рынках малых и средних предприятий? А вот в Америке почему то подобных решений не замечено.
Мы для изменчивых алгоритмов использовали свой доморощенный макроязык ещё десять лет назад. И подобные вещи корректировались прямо на месте у заказчика без всякой перекомпиляции бизнес логики. А уж при уровне нынешних технологий, я вообще не понимаю о чём идёт речь.
AVK>>>Слова Стива Шварца помнишь?
IT>>Какие именно
AVK>Те самые, которые я процитировал в самом начале.
В начале чего
IT>>На практике я вижу какую пургу несут его ребятки из MS на моём проекте. Было бы лучше если бы он приехал и вправил им мозги.
AVK>Напиши ему.
Врад ли поможет.
IT>>Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок
AVK>Так идея то в том чтобы это реализовать один раз, а не каждый раз когда нужна новая бизнес-логика.
А ты ничего не пишешь когда тебе нужна новая бизнеслогика? Странно
IT>>Ты так думаешь потому что тебе это просто пока не приходилось делать
AVK>И, надеюсь, не придется. В технических авантюрах, вызванных бредом воспаленного разума технически безграмотных менеджеров участвовать не собираюсь.
Правильно. Гораздо эффективнее в десятый раз изобрести ещё один велосипед
IT>>Что-то я тут опять мало что понял. Закладвать в архитектуру расширяемость можно и нужно всегда.
AVK>Разумеется. Но не до бесконечности же. Вот ты например закладываешь в архитектуру возможность работы не только с CLR, но и с JVM?
Она у меня уже есть по умолчанию. Называется веб-сервисы
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Alexey Shirshov, Вы писали:
AVK>>А не передергиваешь? Нет, понятно что reference constraint нужно делать средствами БД, но городить навороченные триггеры точно не стоит. Вот у меня под боком живой пример. Обращение к одной из вьюх примерно в 200 раз медленнее прямого доступа к таблице. При этом вьюха отличается всего лишь проверками. Сервер приложений такую проверку сделает со свистом.
AS>С++ порождает код в несколько раз быстрее дотнетовского. Все летает со свистом. Однако же ты используешь дотнет, потому что он проще и на нем легче писать грамотный код. Тут фактически, тот же выбор.
Во-первых насчет нескольких раз ты перебрал, а во-вторых по твоему сложные проверки легче писать не на шарпе, а на tsql, так что ли?
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>Твоей системы конечно. Если у тебя это время не детерминировано, то тогда конечно. В противном же случае, запросы к объектной модели — это часть обеспечения функциональности системы.
ГВ>А... это, в разработку системы вполне может быть включена разработка соответствующих stateful-сервисов.
Это ты АВК расскажи. У него BL-девелоперы такой фигнёй не страдают, у них есть The App-Server, который уже всё умеет
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>А с каких это пор наличие/отсутствие объектных запросов стало прерогативой стейтлес модели? Это совершенно отдельная фича.
Я о прерогативах ничего не говорил.
IT>>Возьми хотя бы кеширование веб-страниц в веб-браузере. При повторном запросе никуда ходить не надо, HTML формировать не надо, даже самого интернета не надо. Страница лежит в кеше и всегда готова к отображению.
AVK>Зато вероятность попадания в такой кеш существенно ниже. Вобщем опять ты кидаешься в крайности. Кеш должен быть по возможности везде.
Ты опять кидаешься ни чем не обоснованными обвинениями. Я разве говорил что кешь должен быть только на клиенте. Я говорил, что он тем эффективнее, чем ближе к потребителю. Чувствуешь разницу?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Alexey Shirshov, Вы писали:
H_D>> а если я его (вот извращение-то) напишу на MC++ в неменеджед классах с менеджед оберткой — оно вообще рулить будет.
AS>За 2 часа? Ох уж этот юношеский максимализм.
Ну почему же? Вполне возможно. Только он потом ещё двое суток это отлаживать будет
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
AVK>>Это уже решение проблемы средствами бизнес-логики, о чем я и говорил.
IT>А ты можешь провести чёткую грань?
Между бизнес-логикой и кодом управления процессом? Могу.
AVK>>А вот предложения ТК и твои лучшим образом это подтвердили. И он и ты постоянно предлагаете мне править прикладной код для решения задачи управления.
IT>Я тебе предлагаю не изобретать велосипеды.
А где я такое предлагал? Вот ваша эмуляция состояний при помощи отдельной БД это точно велосипед. И ваши гуиды вместо нормальных транзакций тоже велосипед.
AVK>>Я? Я пока что ничего не решаю. Я собственно и решения то не предлагал никакого.
IT>То что ни решения, ни одного конкретного примера — это я заметил Всё больше намёки о существовании некоего невероятно крутого сервера приложений
И это неверно. Намеки это у ГВ, а я ни про что не намекал. Я сразу же специально написал — никакой конкретики, одна философия.
AVK>>Это уже детали. Впрочем в данном конкретном случае может оно и прокатит. Не зальешь дистрибутив на сервер?
IT>Надо будет пошукать.
Да, вот тока что товарища с МС проводили. Вобщем не катит похоже бизтолк, не то это. Надо смотреть. Как будет время залезу в msdn, поковыряю его локально.
AVK>>Черт его знает. Пока точно не известно. Вероятность того что это будет коробка не нулевая. Даже если это будет внутренний продукт совершенно точно его будут пользовать внедрюки в различных филиалах.
IT>Так может тогда стоит делать всё по нормальному?
По нормальному это стейтлес?
IT>Для подобных задач существуют решения, но они все жутко дорогие. Причём в чём поинт таких цен я не понимаю
Стоимость предыдущего решения в этом секторе примерно 700 баксов на 5 пользователей.
IT>Я тебе уже доложил. Код о котором ты говоришь вообще писать не надо, его можно рисовать.
По барабану. Я предпочитаю все что можно сделать автоматически, без участия пользователя делать автоматически.
AVK>>Ну да, вроде хранения состояния в БД всегда, даже если его хранить то надо десяток секунд.
IT>Если пользователь нажал Save и перешёл к другой операции, то хранить надо даже пол секунды. Документ, появившийся в системе не должен из неё исчезать бесследно.
Подожди, ты чего то не понял. В пределах транзакции нажатие Save не в корневом контексте не должно приводить к появлению чего то вне транзакции. Это требование ТЗ, обсуждать это бессмысленно. Если оно появилось в системе значит транзакция завершена и говорить вобще не о чем.
AVK>>В незакрытой транзакции? Может конечно, иначе ради чего огород городить?
IT>Т.е. мы опять приходим к тому, что если кончилась батарейка, то тётя Маша, нажавшая за секунду до этого Save, сама дура. Найс. Андрей, ты понимаешь что это не серьёзно?
Что несерьезно? Что при сбое транзакции она должна быть полностью откачена? Я это даже обсуждать не хочу, транзакция без атомарности это не транзакция а какая то фигня.
IT>О том, к чему может привести такая "оптимизация", дети BL-девелоперов проходят в детском саде.
Это уже не оптимизация, это транзакционность и эти самые дети должны понимать что такое транзакция.
AVK>>А кто спорит. Просто необходимость непрерывно переписывать бизнес-логику начисления приводит к возрастанию фактора простоты написания этой бизнес-логики. Ты думаешь почему у 1С предприятия практичеси полное доминирование на рынках малых и средних предприятий? А вот в Америке почему то подобных решений не замечено.
IT> И подобные вещи корректировались прямо на месте у заказчика без всякой перекомпиляции бизнес логики. А уж при уровне нынешних технологий, я вообще не понимаю о чём идёт речь.
Вот о том и речь что не понимаешь. Фишка не в правке чего то вами без перекомпиляции, фишка в возможности глубокой правки системы самим заказчиком вплоть до добавления своих документов, OLTP регистров и прочая. МС вот грозится выпустить на российский рынок MBF и выгнать с него 1С и всех остальных, но это будет относительно нескоро. А пока же никаких подходящих западных решений для малого и среднего бизнеса нет.
AVK>>Те самые, которые я процитировал в самом начале.
IT>В начале чего
Разговора.
IT>>>На практике я вижу какую пургу несут его ребятки из MS на моём проекте. Было бы лучше если бы он приехал и вправил им мозги.
AVK>>Напиши ему.
IT>Врад ли поможет.
Ну ты напиши, а потом обсудим, помогло или нет
IT>>>Это из той же серии C# vs C++. Stateful открывает самый широкий простор для совершения ошибок
AVK>>Так идея то в том чтобы это реализовать один раз, а не каждый раз когда нужна новая бизнес-логика.
IT>А ты ничего не пишешь когда тебе нужна новая бизнеслогика?
В ядре то? Нет конечно. Я (ну не я конечно) пишу исключительно бизнес-логику. Уж точно не пишу каждый раз механику отката, как здесь предлагается.
AVK>>И, надеюсь, не придется. В технических авантюрах, вызванных бредом воспаленного разума технически безграмотных менеджеров участвовать не собираюсь.
IT>Правильно. Гораздо эффективнее в десятый раз изобрести ещё один велосипед
Пока что велосипед предлагаешь ты. На рынке вобще пока очень мало готовых многозвенных решений, тем более под дотнет, так что ни о каких велосипедах и речи быть не может.
AVK>>Разумеется. Но не до бесконечности же. Вот ты например закладываешь в архитектуру возможность работы не только с CLR, но и с JVM?
IT>Она у меня уже есть по умолчанию. Называется веб-сервисы
Ну попробуй свой вебсервис где нить в джаве заюзать, потом вместе смеятся будем
Здравствуйте, IT, Вы писали:
AVK>>Давай не будем ограничивать свои знания продуктами МС. Названия WebLogic, EAS тебе о чем нибудь говорят?
IT>Говорят о тормознутости.
Ты с ними сам работал? А то вон почитаешь про mssql у ораклей так тоже такой тормоз что мама дорогая.
Здравствуйте, IT, Вы писали:
AVK>>А с каких это пор наличие/отсутствие объектных запросов стало прерогативой стейтлес модели? Это совершенно отдельная фича.
IT>Я о прерогативах ничего не говорил.
То есть речь уже не о stateless/stateful? Ну тогда я пас.
AVK>>Зато вероятность попадания в такой кеш существенно ниже. Вобщем опять ты кидаешься в крайности. Кеш должен быть по возможности везде.
IT>Ты опять кидаешься ни чем не обоснованными обвинениями. Я разве говорил что кешь должен быть только на клиенте. Я говорил, что он тем эффективнее, чем ближе к потребителю. Чувствуешь разницу?
Ну IT, от тебя я такого не ожидал, обычно этим несколько другой человек страдает.
Я об этом.
если принять во внимание, что кеш тем эффективнее, чем он ближе к клиенту,
Это обобщение неверно, поскольку ты учитываешь только время доступа к кешу и не учитываешь коэффициент попадания, который с точностью до наоборот — чем ближе к клиенту тем хуже. Итого суммарная эффективность кеша зависит от обоих показателей. И где у итоговой функции максимум я вот так сказать не берусь.
Здравствуйте, IT, Вы писали:
IT>Вот может ты и дашь определение как автор этого термина
Да не ребята, я в отличие от вас свою трактовку вводить не собираюсь.
stateless object объект, не меняющий своего состояния в процессе исполнения
stateful object объект, кумулятивно изменяющий параметры своего состояния в процессе исполнения по вызовам клиентов
Здравствуйте, AndrewVK, Вы писали:
AVK>>>А с каких это пор наличие/отсутствие объектных запросов стало прерогативой стейтлес модели? Это совершенно отдельная фича.
IT>>Я о прерогативах ничего не говорил.
AVK>То есть речь уже не о stateless/stateful? Ну тогда я пас.
Не надо выворачивать. Я ничего не говорил о наличии/отсутствии объектных запросов в стайтлес модели.
AVK>>>Зато вероятность попадания в такой кеш существенно ниже. Вобщем опять ты кидаешься в крайности. Кеш должен быть по возможности везде.
IT>>Ты опять кидаешься ни чем не обоснованными обвинениями. Я разве говорил что кешь должен быть только на клиенте. Я говорил, что он тем эффективнее, чем ближе к потребителю. Чувствуешь разницу?
AVK>Ну IT, от тебя я такого не ожидал, обычно этим несколько другой человек страдает. AVK>Я об этом. AVK>
AVK> если принять во внимание, что кеш тем эффективнее, чем он ближе к клиенту,
AVK>Это обобщение неверно, поскольку ты учитываешь только время доступа к кешу и не учитываешь коэффициент попадания, который с точностью до наоборот — чем ближе к клиенту тем хуже. Итого суммарная эффективность кеша зависит от обоих показателей. И где у итоговой функции максимум я вот так сказать не берусь.
Если я вынесу справочники на клиента, то попадание всегда будет 100%. Что здесь не так? К тому же чем ближе к клиенту, тем уже более обработаны данные. Или тебе еще раз привести пример с браузером?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
IT>>Говорят о тормознутости.
AVK>Ты с ними сам работал? А то вон почитаешь про mssql у ораклей так тоже такой тормоз что мама дорогая.
А ты? Я наблюдал как с этим г. (извиняюсь за выражение) парился народ который нам устанавливал это барахло. Зная сколько стоит под это техника и сколько сам софт. Всё это шевелица только благодаря супермощной технике, за которую платит между прочим заказчик.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>Да не ребята, я в отличие от вас свою трактовку вводить не собираюсь.
AVK>stateless object объект, не меняющий своего состояния в процессе исполнения AVK>stateful object объект, кумулятивно изменяющий параметры своего состояния в процессе исполнения по вызовам клиентов
Что такое stateless и stateful мы и без тебя знаем. Ты нам растолкуй, что ты понимаешь под термином 'состояние'. А то пока я вижу, что ты меняешь его трактовку в зависимости от контекста.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
незадача, однако...
