Здравствуйте, AndrewVK, Вы писали:

IT>>Понял. Моё решение могло бы быть таким.
IT>>Баба Маня вводит документы локально.

AVK>Опаньки. Значит состояние надо на клиенте держать? Проблемы перечислить или и так понятно?

Начинай

IT>>При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

AVK>Абалдеть. ООП в действии .

Ага, ты мне ещё про полиморфик бихейвор расскажы
Дон Бокс тебе же ясно сказал — ООП идёт лесом

AVK>Данные отдельно, алгоритмы отдельно.

Точно.

AVK>Только вот нифига не выйдет так — в алгоритмах рассчетов практически всегда фигурируют только что введенные данные.

Почему? Данные же были введены отдельно от алгоритмов

AVK>Единственный способ в таком варианте — гнать данные на сервер. Это тот самый случай когда стейтлес вносит жуткий оверхед, что и требовалось доказать.

Ну если гнать бездумно, то и доказывать не надо. К тому же ты и так всё гонишь, документы на сервере ведь не в огороде рождаются.

IT>> Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу.

AVK>А если в процессе ввода документов нужно автоматически добавлять какие то объекты? На клиенте добавлять?

Зависит от задачи. Дай мне больше информации, я тебе дам ответ на твой вопрос.

AVK>Но это ведб БЛ, а она допустима только на сервере!

Кто тебе сказал? Я уже говрил, валидация — это часть БЛ, но должна выполнятся в том числе и на клиенте во избежании раунд-трипов.

IT>> Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

IT>>Stateless в чистом виде

AVK>Ага.

Дык

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Баба Маня вводит документы локально. При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

ГВ>Вот здесь главная закавыка. Логика, которая определяет необходимые данные, вероятно, "уходит" на клиента.

Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

IT>>Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу. Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.

IT>>Stateless в чистом виде

ГВ>То-то и оно, что stateless, да ещё и с разгруженным SQL-сервером.

А тебе нужен stateful с загруженным?

ГВ>Сначала тебе нужно гонять избранные фрагменты (которые нужно программить вручную) для обсчёта промежуточных величин, а потом — полное тело документа.

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

ГВ>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.

Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

ГВ>Плюс — продублировать вычисления после отправки завершённого документа.

Зависит.

Здравствуйте, AndrewVK, Вы писали:

AVK>Причем логика взаимодействия этих документов и предварительных расчетов (например посчитать сумму по больничному) должна быть на сервере, это не обсуждается, это часть ТЗ.

Кстати, давно хотел тебя спросить
А "логика на сервере" как часть ТЗ — это круто. Где такого заказчика нашёл? Как минимум товарищ должен быть очень не слабо технически подкован, что бы решать такие вопросы. Уж не ты ли его подковывал?

IT>Где такого заказчика нашёл? Как минимум товарищ должен быть очень не слабо технически подкован, что бы решать такие вопросы. Уж не ты ли его подковывал?

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

Здравствуйте, IT, Вы писали:

AVK>>Опаньки. Значит состояние надо на клиенте держать? Проблемы перечислить или и так понятно?

IT>Начинай

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

IT>>>При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.

AVK>>Абалдеть. ООП в действии .

IT>Ага, ты мне ещё про полиморфик бихейвор расскажы
IT>Дон Бокс тебе же ясно сказал — ООП идёт лесом

А я не пионер чтобы безоговорочно верить вождям революции.

AVK>>Только вот нифига не выйдет так — в алгоритмах рассчетов практически всегда фигурируют только что введенные данные.

IT>Почему? Данные же были введены отдельно от алгоритмов

Я тебе пример привел — рассчет больничного. При расчете необходим как сам больничный так и вся зарплата сотрудника за несколько месяцев. Что — считаем на клиенте? Или на сервере? И в том и в другом случае получаем оверхед на перекачку состояний.

AVK>>Единственный способ в таком варианте — гнать данные на сервер. Это тот самый случай когда стейтлес вносит жуткий оверхед, что и требовалось доказать.

IT>Ну если гнать бездумно, то и доказывать не надо.

А не бездумно это как?

IT> К тому же ты и так всё гонишь, документы на сервере ведь не в огороде рождаются.

Я это делаю один раз, а не каждый раз когда мне пересчитать надо.

IT>>> Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу.

AVK>>А если в процессе ввода документов нужно автоматически добавлять какие то объекты? На клиенте добавлять?

IT>Зависит от задачи. Дай мне больше информации, я тебе дам ответ на твой вопрос.

Не зависит от задачи. Клиент должен быть универсальным и никак не зависеть от конкретного приложения. Писать специализированного клиента под каждую задачку никто не будет.

AVK>>Но это ведб БЛ, а она допустима только на сервере!

IT>Кто тебе сказал?

Начальник сказал. Тебя так устроит? Или будем дискутировать о допустимости бизнес-логики на клиенте? Но это уже спор не о модели хранения состояний, а о самой структуре n-tier. Если твоя замечательная архитектура приводит к различным извращениям вроде регулярной транспортировки состояний и выносу БЛ на клиента то это проблемы твоей архитектуры и очень странно что ты этих проблем не видишь.

IT> Я уже говрил, валидация — это часть БЛ, но должна выполнятся в том числе и на клиенте во избежании раунд-трипов.

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

AVK>>Ага.

IT>Дык

Дык вот я тебя и поймал — ты очень наглядно продемонстрировал плохую применимость стейтлес модели для подобных задачек.

Здравствуйте, IT, Вы писали:

ГВ>>Вот здесь главная закавыка. Логика, которая определяет необходимые данные, вероятно, "уходит" на клиента.

IT>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

У меня есть — логика и данные на сервере . На клиенте только интерфейс.

IT>А у тебя есть конкретная информация об этих самых величинах? Может там всего лишь надо посчитать НДС от заданной суммы. Восемь байт туда, восемь сюда. Какие проблемы?

Ох IT, не одним НДС все обходится.

IT>Вот когда АВК расколется, тогда и будем об этом рассуждать.

Я тебе уже сказал — давай обсудим предварительные расчеты больничных и отпусков. Типовая задачка в зарплате.

ГВ>>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.

IT>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

И вся правка на смарку? Замечательно.

Здравствуйте, IT, Вы писали:

IT>>>Баба Маня вводит документы локально. При необходимости посчитать что-то на сервере ему выдаются необходимые данные и он их считает.
ГВ>>Вот здесь главная закавыка. Логика, которая определяет необходимые данные, вероятно, "уходит" на клиента.
IT>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

Логика и данные на сервере (серверах). На клиенте — только презентация.

IT>>>Если баба Маня нажимает Esc, то всё умирает не обращаясь к серверу. Если она нажимает Save, то сервер все данные сохраняет одной транзакцией.
IT>>>Stateless в чистом виде
ГВ>>То-то и оно, что stateless, да ещё и с разгруженным SQL-сервером.
IT>А тебе нужен stateful с загруженным?

От stateless мне ничего н нужно. Разгрузка SQL-сервера в твоём случае означает вытаскивание колтуна из логики и состояний на клиента.

ГВ>>Сначала тебе нужно гонять избранные фрагменты (которые нужно программить вручную) для обсчёта промежуточных величин, а потом — полное тело документа.
IT>А у тебя есть конкретная информация об этих самых величинах? Может там всего лишь надо посчитать НДС от заданной суммы. Восемь байт туда, восемь сюда. Какие проблемы? Вот когда АВК расколется, тогда и будем об этом рассуждать.

Он уже раскололся. Кстати, величина НДС от заданной суммы тожет зависит от разных величин. Зависело, во всяком случае... правда, последних изменений в законодательстве на эту тему я не знаю.

Да и твои 8 байт сюда 8 сюда на практике всё равно превратятся примерно в килобайт.

ГВ>>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.
IT>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

И что ты собираешься в блоке catch писать?

ГВ>>Плюс — продублировать вычисления после отправки завершённого документа.
IT>Зависит.

Не-а, поскольку тебе обязательно нужно убедиться, что данные не перекорёжены по пути, что клиенсткие скрипты отработали правильно и т.д., и т.п.

Здравствуйте, IT, Вы писали:

IT>Ага, ты мне ещё про полиморфик бихейвор расскажы
IT>Дон Бокс тебе же ясно сказал — ООП идёт лесом

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

Здравствуйте, Alexey Shirshov, Вы писали:

AVK>>Во-первых насчет нескольких раз ты перебрал, а во-вторых по твоему сложные проверки легче писать не на шарпе, а на tsql, так что ли?

AS>Конечно, нет. Я лишь говорю, что все проверки ограничений целостности, уникальности и другие обязаны присутствовать в sql-сервере, даже если они дублируются на коде бизнес-логики и на клиенте.

Нет, не все и не всегда. Всё зависит от того, как использутся SQL-сервер. Если кроме App-сервера в одну и ту же базу лезет ещё два десяька модулей (они же — сервисы и проч.), то делать нечего — надо тащить в SQL-сервер всё подряд, хотя бы для того, чтобы не дублировать БЛ сервисов и App-сервера (его прикладных компонент). А если работаешь "по-грамотному", то есть, App-сервер — это единственный "шлюз" в базу данных, то... короче говоря, всё подряд в него абсолютно необязательно пихать.

Здравствуйте, AndrewVK, Вы писали:

IT>>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

AVK>У меня есть — логика и данные на сервере . На клиенте только интерфейс.

Это уже веб-браузер получается. Самый тонкий клиент в мире

IT>>Вот когда АВК расколется, тогда и будем об этом рассуждать.

AVK>Я тебе уже сказал — давай обсудим предварительные расчеты больничных и отпусков. Типовая задачка в зарплате.

Непременно обсудим

IT>>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

AVK>И вся правка на смарку? Замечательно.

Зачем же так жестоко. Исключение выброшенное на сервере обычно обрабатывается клиентом, который докладывает бабе Мане, в чём именно она не права.

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

ГВ>Логика и данные на сервере (серверах). На клиенте — только презентация.

А презентация у тебя что отображает? Банеры что ли

IT>>А тебе нужен stateful с загруженным?

ГВ>От stateless мне ничего н нужно. Разгрузка SQL-сервера в твоём случае означает вытаскивание колтуна из логики и состояний на клиента.

Простите, вытаскивание кого?

ГВ>Да и твои 8 байт сюда 8 сюда на практике всё равно превратятся примерно в килобайт.

Всё зависит от задачи, я предпочитаю взвешенный подход (с) АВК

ГВ>>>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.
IT>>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)

ГВ>И что ты собираешься в блоке catch писать?

Показывать бабе Мане что произошло.

ГВ>>>Плюс — продублировать вычисления после отправки завершённого документа.
IT>>Зависит.

ГВ>Не-а, поскольку тебе обязательно нужно убедиться, что данные не перекорёжены по пути, что клиенсткие скрипты отработали правильно и т.д., и т.п.

Что значит перекорёжены по пути? Кабель что ли перекручен или где-то на него водопровод протекает?

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Дон Бокс тебе же ясно сказал — ООП идёт лесом

ГВ>Дона Бокса, похоже, давно уж кроме коммуникаций ничего не интересует. Пусть говорит, что ему больше нравится, кто же запретит.

Как это не печально, но его прежде всего интересует то, что ты будешь использовать через несколько лет.

Здравствуйте, AndrewVK, Вы писали:

IT>>Где такого заказчика нашёл? Как минимум товарищ должен быть очень не слабо технически подкован, что бы решать такие вопросы. Уж не ты ли его подковывал?

AVK>Нет, заказчик у меня не конечный пользователь, а фирма, поскольку пишу я не какое то частное решение а платформу.

Фирма чья?

Здравствуйте, AndrewVK, Вы писали:

AVK>Необходимость гонять его на сервер,

Что-то гонять по любому приходится. Вопрос только в том, как это минимизировать.

AVK>крайняя сложность поддержания актуального состояния

Ты же говорил, что у тебя в один момент с этим документом только один клиент работает. Какие тогда могут быть проблемы с актуальностью.

AVK>вынос логики управления длинными транзакциями на клиента,

Ничего страшного.

AVK>низкая надежность.

Да ну? Может всё совсем наоборот? Наверняка ты в таймлайфах теперь большой эксперт Как ты интересно своему объекту жизнь продлеваешь? Или он у тебя на сервере висит пока сервер не перегрузят?

AVK>>>Абалдеть. ООП в действии .

IT>>Ага, ты мне ещё про полиморфик бихейвор расскажы
IT>>Дон Бокс тебе же ясно сказал — ООП идёт лесом

AVK>А я не пионер чтобы безоговорочно верить вождям революции.

Раз мы не пионеры, то давай не будем друг друга лечить всякими лозунгами про ООП. Когда он мне помогает, я его применяю не хуже тебя. Когда мещает, то идёт лесом под барабанную дробь Дона Бокса. Правда, надо признать, таких ситуаций почти не бывает (даже не взирая на слова Бокса ).

AVK>Я тебе пример привел — рассчет больничного. При расчете необходим как сам больничный так и вся зарплата сотрудника за несколько месяцев. Что — считаем на клиенте? Или на сервере? И в том и в другом случае получаем оверхед на перекачку состояний.

Зависит от задачки (можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте. Насколько мне известно, все зарплаты, которые я когда либо видел и делал, работают именно по такому принципу. А вот пакетный расчёт можно делать и на сервере.

IT>>Ну если гнать бездумно, то и доказывать не надо.

AVK>А не бездумно это как?

Зависит от задачки

AVK>Не зависит от задачи. Клиент должен быть универсальным и никак не зависеть от конкретного приложения. Писать специализированного клиента под каждую задачку никто не будет.

Универсальный клиент — это веб-браузер. Можно сделать менее универсальный, который будет хостить определённые расчитанные на него UI-модули. Можно сделать специализированный фрэймворк и соответственно уменьшить затраты на разработку самих модулей. Можно вообще ничего не универсиализировать. Но в любом случае, чем более или менее универсальнее твой UI-хост, тем больше писать кода в UI. Наилучший вариант где-то посередине. Так что зависит.

IT>>Кто тебе сказал?

AVK>Начальник сказал. Тебя так устроит? Или будем дискутировать о допустимости бизнес-логики на клиенте? Но это уже спор не о модели хранения состояний, а о самой структуре n-tier.

Об этом тоже можно поспорить. Всё зависит от задачки... ну ты знаешь

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

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

IT>> Я уже говрил, валидация — это часть БЛ, но должна выполнятся в том числе и на клиенте во избежании раунд-трипов.

AVK>Какая к черту валидация. Нужно считать и создавать новые объекты по ходу ввода документа. Документы не заканчиваются примитивными накладными, которые легко упихать в стейтлес-модель. Докуенты могут иметь очень сложную структуру с кучей подчиненных.

Вот то-то и оно.

IT>>Дык

AVK>Дык вот я тебя и поймал — ты очень наглядно продемонстрировал плохую применимость стейтлес модели для подобных задачек.

Должен тебя огорчить. К твоему сожалению, ты меня не поймал, а сам попался в искусно расставленные сети
С тобой невозможно спорить, так как ты никогда не приводишь конкретных фактов и примеров. Лишь редкие намёки на крутизну принятых решений. В результате получается разговор не о чём. Но теперь то мы знаем, что задачка, которую ты делаешь — это зарплатка

Вот о ней и поговорим.

О сложности самой задачи мне рассказвать не надо. Первый раз я с ней столкнулся больше 10 лет назад. Да, действительно, задача сложная и слабоформализуемая благодаря неожиданности российского законодательства и многообразию необходимых данных. Скорее всего, самая тяжёлая из бухгалтерских задач. Далше только склад. Возможно я действительно поотстал от жизни и почему-то думал, что время таких задач уже давно прошло, всё уже понаписано. Ан нет. Видимо пошёл второй (или третий круг). Да ещё с привлечением тяжёлой артиллерии в виде апп-серверов Круто!

Только то, как ты это делаешь — это конечно же нонсенс. Ты бы ещё предложил редактировать Excel файл, расположенный в памяти апп-сервере. Любой стэйтфул не надёжен по определению, т.к. память пока является самым ненадёжным хранилищем данных. Всё это помножается на ненадёжность сети и локальной машины, сложность ПО и поддержки. Если хранить документ в памяти локального компьютера, то он конечно тоже в памяти, но пользователь чётко знает и видит, что происходит. Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless. Подготовка (сколь угодно сложная) документа на клиенте, запрос к серверу, обработка данных сервером приложений, сохранение данных в базе, возврат пользователю информации об успешности транзакции. Всё просто, надёжно и быстро. Каждая часть системы занимается своим делом, тем для чего она предназначена и что у неё лучше получается.

Ты же явно перемудрил. То что ты называешь длинными транзакциями на самом деле называется режимом Undo/Redo. Ничего необычного. Правда иногда сложно реализуется для сложных документов.

Логика для таких задач практически не формализуется и меняется настолько часто, что её нужно выность не то что в БЛ, а вообще из кода проекта. Необходимо либо задействовать скрипты, либо подключаемые обновляемые модули. Переписывать БЛ под каждый чих правительсьтва — это чушь. 10 лет назад мы делали свой С-подобный язык, хранили скрипты в базе и подгружали их по мере необходимости. Сейчас существуют более продвинутые технологии. В качестве скриптового языка можно задействовать любой язык .NET или сразу все. Да ты и сам это знаешь не хуже меня. Можно хранить такие скрипты в виде текста или же подгружать сборки с обновлениями. Но в любом случае, это лучше делать на клиенте. На сервере они тоже пригодятся для пакетных расчётов, но перерасчёт во время ввода данных на сервер отдавать совершенно нет никакого резона (если этот расчёт при вводе данных вообще нужен).

Никакой такой особенной синхронизации данных на сервере эта задача не требует. Зарплатой даже в больших конторах занимается как правило один человек, обычно зам. главбуха. В очень больших — небольшая группа бухгалтеров, между которыми чётко распределены обязанности, и табельщики, которые никаких расчётов не выполняют, а только вводят часы и больничные. Чтобы не было конфликтов, достаточно воспользоваться простым способом с маркировкой записей, который я приводил выше. Если же вдруг один из бухгалтеров подредактирует данные, которыми в данный момент занимается другой, то ему тут же надают по кумполу, чтобы в следующий раз согласовывал свои действия. Ну в самом крайнем случае можно что-нибудь придумать для блокировок.

Больших вычислительных мощностей для этой задачи тоже не надо. Расширяемость ей сильно не грозит, тут ты прав. Но и stateful здесь как телеге пятое колесо. Обычная настольная задача со сложной структурой документов и запутанными расчётами, которой мощность серверов приложений ни к чему.

В общем, я могу понять только один твой аргумент — так сказал начальник. Ну что же, передавай ему от меня большой stateful привет!

Здравствуйте, IT, Вы писали:

IT>>>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?
ГВ>>Логика и данные на сервере (серверах). На клиенте — только презентация.
IT>А презентация у тебя что отображает? Банеры что ли

Только то, что определено приложением, как доступное пользователю для просмотра или редактирования.

IT>>>А тебе нужен stateful с загруженным?
ГВ>>От stateless мне ничего н нужно. Разгрузка SQL-сервера в твоём случае означает вытаскивание колтуна из логики и состояний на клиента.
IT>Простите, вытаскивание кого?

Колтуна. Когда состояние полностью дублируется на клиенте. Собственно, "колтуном" я это назвал, не потому, что вытаскивается на клиента, а потому что придётся скорее всего вручную всё это выписывать.

ГВ>>Да и твои 8 байт сюда 8 сюда на практике всё равно превратятся примерно в килобайт.
IT>Всё зависит от задачи, я предпочитаю взвешенный подход (с) АВК

Да, естественно. Только вот минимальный размер IP-пакета, если мне не изменяет память, всё-таки 60 байт, а если ещё и соединение переоткрывать... а если ещё http...

ГВ>>>>Плюс — обработать разные хитрые ситуации отказов промежуточного обсчёта и т.п.
IT>>>Все хитрые ситуации сводятся к выбрасыванию исключения, которое легко ловится блоком try/catch (если ты не в курсе)
ГВ>>И что ты собираешься в блоке catch писать?
IT>Показывать бабе Мане что произошло.

Это-то понятно, а с приложением что ты делать собираешься?

ГВ>>>>Плюс — продублировать вычисления после отправки завершённого документа.
IT>>>Зависит.
ГВ>>Не-а, поскольку тебе обязательно нужно убедиться, что данные не перекорёжены по пути, что клиенсткие скрипты отработали правильно и т.д., и т.п.
IT>Что значит перекорёжены по пути? Кабель что ли перекручен или где-то на него водопровод протекает?

И это тоже. Ошибки и при упаковке могут быть, и при распаковке, особенно, если их вручную писать.

Здравствуйте, IT, Вы писали:

IT>>>Дон Бокс тебе же ясно сказал — ООП идёт лесом
ГВ>>Дона Бокса, похоже, давно уж кроме коммуникаций ничего не интересует. Пусть говорит, что ему больше нравится, кто же запретит.
IT>Как это не печально, но его прежде всего интересует то, что ты будешь использовать через несколько лет.

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

Здравствуйте, IT, Вы писали:

IT>Фирма чья?

В которой я раюотаю

Здравствуйте, IT, Вы писали:

AVK>>крайняя сложность поддержания актуального состояния

IT>Ты же говорил, что у тебя в один момент с этим документом только один клиент работает. Какие тогда могут быть проблемы с актуальностью.

А сам документ может данные тягать из других документов.

AVK>>вынос логики управления длинными транзакциями на клиента,

IT>Ничего страшного.

Ну если тебе не страшно тогда собственно дальше говорить не о чем. У меня подходы другие. Доверять управление транзакциями клиенту для меня неприемлемо.

AVK>>низкая надежность.

IT>Да ну? Может всё совсем наоборот? Наверняка ты в таймлайфах теперь большой эксперт Как ты интересно своему объекту жизнь продлеваешь? Или он у тебя на сервере висит пока сервер не перегрузят?

При чем тут таймлайф? Вероятность сбоя любого из клиентов значительно выше вероятности сбоя единственного сервера.

IT>>>Ага, ты мне ещё про полиморфик бихейвор расскажы
IT>>>Дон Бокс тебе же ясно сказал — ООП идёт лесом

AVK>>А я не пионер чтобы безоговорочно верить вождям революции.

IT>Раз мы не пионеры, то давай не будем друг друга лечить всякими лозунгами про ООП.

А где я тебя лозунгами лечил? Ты наверное меня с кем то спутал.

IT> Когда он мне помогает, я его применяю не хуже тебя. Когда мещает, то идёт лесом под барабанную дробь Дона Бокса. Правда, надо признать, таких ситуаций почти не бывает (даже не взирая на слова Бокса ).

А вот у меня как раз больше ситуаций когда идеи Бокса идут лесом. В этом и проблема.

AVK>>Я тебе пример привел — рассчет больничного. При расчете необходим как сам больничный так и вся зарплата сотрудника за несколько месяцев. Что — считаем на клиенте? Или на сервере? И в том и в другом случае получаем оверхед на перекачку состояний.

IT>Зависит от задачки

Ты читаешь внимательно? Задача — рассчет больничного.

IT>(можно я немножко попользуюсь этой твоей фразой) Можно считать и на клиенте.

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

IT> Насколько мне известно, все зарплаты, которые я когда либо видел и делал, работают именно по такому принципу.

Ну значит ты не делал зарплату на трехзвенке.

IT> А вот пакетный расчёт можно делать и на сервере.

Но это уже классический клиент-сервер, а не трехзвенка. Неплохая технология, спору нет, но опять же со своими недостатками.

AVK>>Не зависит от задачи. Клиент должен быть универсальным и никак не зависеть от конкретного приложения. Писать специализированного клиента под каждую задачку никто не будет.

IT>Универсальный клиент — это веб-браузер.

И это верно. Но вот только не всегда веб-интерфейс прокатывает.

IT> Можно сделать менее универсальный, который будет хостить определённые расчитанные на него UI-модули.

Так и делается.

IT>Но в любом случае, чем более или менее универсальнее твой UI-хост, тем больше писать кода в UI. Наилучший вариант где-то посередине. Так что зависит.

Зависит. В моем случае, если тебе интересно, приложений будет большое количество. Отсюда и требование универсального клиента.

AVK>>Начальник сказал. Тебя так устроит? Или будем дискутировать о допустимости бизнес-логики на клиенте? Но это уже спор не о модели хранения состояний, а о самой структуре n-tier.

IT>Об этом тоже можно поспорить.

Можно, но мне что то не хочется. Я вот все о наших баранах, о том что стейтлес не всегда лучшее решение.

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

IT>Моей архитектуре пока этого не надо.

Твоему заказчику не надо. Я тебе об этом постоянно твержу. Не надо только на основании своих конкретных задач делать далеко идущие обобщения.

IT>О сложности самой задачи мне рассказвать не надо. Первый раз я с ней столкнулся больше 10 лет назад. Да, действительно, задача сложная и слабоформализуемая благодаря неожиданности российского законодательства и многообразию необходимых данных. Скорее всего, самая тяжёлая из бухгалтерских задач. Далше только склад.

Да нет, со складом свои, другие заморочки.

IT>Возможно я действительно поотстал от жизни и почему-то думал, что время таких задач уже давно прошло, всё уже понаписано.

Как можно написать то что еще не придумано? Если бы у нас приняли законодательство один раз и навсегда все бы было хорошо. А на практике постоянно приходится латать и перелатывать.

IT>Только то, как ты это делаешь — это конечно же нонсенс. Ты бы ещё предложил редактировать Excel файл, расположенный в памяти апп-сервере.

Давай не будем передергивать.

IT> Любой стэйтфул не надёжен по определению, т.к. память пока является самым ненадёжным хранилищем данных.

Так батенька даже sql-сервер данные хранит в том числе и в памяти. Вот только память на сервере куда надежнее памяти на клиенте.
IT>Если хранить документ в памяти локального компьютера, то он конечно тоже в памяти, но пользователь чётко знает и видит, что происходит.

Вот только не надо переходить на демагогию. При чем тут понимание пользователя? Пользователю плевать где и что хранится.

IT> Любой идиот понимает, что пока он не нажал Save и не получил ответ OK, данные ещё не сохранены. В общем-то так и делается в stateless.

Точно так же и в стейтфул.

IT>Ты же явно перемудрил. То что ты называешь длинными транзакциями на самом деле называется режимом Undo/Redo.

Ага, со вложенностью, многоуровневый, версионный и с автоматическим откатом только. А так да, обычный Undo/Redo .

Здравствуйте, IT, Вы писали:

IT>>>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?

AVK>>У меня есть — логика и данные на сервере . На клиенте только интерфейс.

IT>Это уже веб-браузер получается. Самый тонкий клиент в мире

Эк у тебя однобоко. Если тонкий клиент так сразу браузер. Тонкие GUI клиенты тоже имеют право на существование.

Здравствуйте, AndrewVK, Вы писали:

IT>>>>Одно из двух. Либо логика на клиента, либо данные на сервер. У тебя есть ещё варианты?
AVK>>>У меня есть — логика и данные на сервере . На клиенте только интерфейс.
IT>>Это уже веб-браузер получается. Самый тонкий клиент в мире
AVK>Эк у тебя однобоко. Если тонкий клиент так сразу браузер. Тонкие GUI клиенты тоже имеют право на существование.

Я скажу больше — существуют и не в единственном экземпляре.