Архитектура софта: веб-сервис, тонкий или толстый клиент, что лучше? : Операционные системы и программное обеспечение

1. Не я занимаю агрессивную и непримиримую позицию. Я как раз наоборот, пишу, что надо брать тот инструмент, который в конкретном случае позволяет эффективно решать задачи. Понимаю, что я общаюсь в вебе, тут в головах у людей специфическое восприятие.
2. Я не просто "пробую" писать в вебе, у меня есть пара реально работающих проектов. И это не база штрих-кодов.
3. Погугли на тему rebase. Это механизм для загрузки dll в определенную область памяти, позволяющий расшаривать их использование запущенными экземплярами приложения. На терминальных серверах это выполняется автоматически. Возможно, ты путаешь с веб броузером, в котором запущенные сеансы не могут обращаться друг к другу по соображениям безопасности.
4. Верить или нет, твое дело. Я написал, как есть. Забавно, был случай как раз в этой конторе. У них вылезли какие-то проблемаы с печатью. Того системщика, которому я обычно переадресую подобные вопросы, не было на месте, предложил другого, у которого офис был в соседнем здании. Вроде мужик с опытом, админил на приличном заводе. Потом рассказывают, Слава, ты кого нам прислал? Он пришел, посмотрел характеристики сервера и сказал, что надо сервер менять, так как при таких характеристиках все должно тормозить. Ему говорят, у нас ничего не тормозит, только с принтером проблема. И она вот только появилась (то ли поменяли, то ли из ремонта вернули). Типа разводит на деньги, не присылай больше его. Больше к нему я не обращался. То есть сказки про калькулятор можешь оставить для студентов, которые готовы и не такому поверить.
5. Я просто описываю, что происходит в реальном мире. И говорю, что web технологии имеют недостатки, которые делают их применение нецелесообразным здесь и сейчас. Это примерно как Слава любит горький шоколад, а Олег молочный. И Олег говорит, что горький шоколад скоро больше производить не буду, надо есть только молочный. И это прогресс. Но я не хочу есть молочный, сам его ешь. А я буду есть то, что нравится мне, а не кому-то еще. Я соглашусь с тем, что в таком случае не надо разговаривать с любителями молочного шоколада, а надо разговаривать с любителями горько. Все рассуждения о том, что есть современно, а что нет, крайне субъективны. Даже среди фанатиков веба такой срач идет. Одни пишут, пхп помер, не надо его использовать больше. Другие, пора всем на джанго, питон наше все, джаваскрипт отстой. Жертвы прогресса...

Кстати, мой последний ролик воспроизводится? Я его на большом мониторе записывал. На основном компьютере и на ноуте все работает, а на планшете не хочет. Обратил внимание.

Воспроизводится. Занимательное. Конструктор UI для доступа к базе, конечно, страшненький на вид, но если функционал устраивает, то рад за вас. Непонятно, правда, как быть с бизнес логикой? Как такая штука работает с файловой системой? Что на тему парсинга и генерации документов, и документооборот в целом? Не бывает ли проблем с параллельным доступом юзверей к сущностям?

Ты бы цитировал, на что отвечаешь, контекст порой совсем непонятен... Номера к чему, я так и не понял.
Можно детали, на чем работают, на чем код, какой веб-сервер и т.п.? Просто с вебом ты явно очень отдаленно знаком, даже по использованию терминологии видно.
Раз ты сильнее в винде, можешь ссылочку на текущую документацию про автоматический rebase в TS? Пока выглядит так, как выглядит. То есть никакого деления библиотек между сеансами.
То есть ты лично видел, как 10 человек сидели в сессях терминального сервера, в сложной учетной программе, и все летало? Или все же сосед рассказывал?
Нет, это как Слава любит паровые двигатели и настаивает, что за ними будущее, а Олег удивляется, почему Слава не признает двигатели внутреннего сгорания.
У меня нет, формат кривой, видимо....

В настоящий момент две системы - электронные заказы (наподобии интернет магазина, только со специфичным функционалом) и веб морда к системе лояльности (скидочные карты). Ну и по мелочам всякое. Использовался php без cms и фреймворков. Вот пример.



У меня такой ссылки нет. Давно выясняли и обсуждали в русскоязычных группах. Про rebase тема недавно у англоязычных всплывала, где-то год назад. Есть такой шаблон, который цепляется к проекту перед компиляцией. Я им не пользуюсь, смотрел только когда-то. Лишние телодвижения, проект часто пересобирается.

Это мои клиенты и на моей учетной системе. Разумеется, своими глазами вижу, я к ним время от времени подключаюсь по каким-то учетным вопросам.

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

Судя по скриншоту, специфики нет от слова совсем, как и серьёзной бизнес-логики. Банальный e-commerce, видимо, B2B. Можно ли считать такое вэб приложением? Ну, с сильной натяжкой. Просто для удобства клиентов дополнили телефонные звонки и имейлы онлайн формой, отправляющей тот же имейл. Если есть связь с какой-то ERP, то это здорово, хотя сути не меняет. Был ли смысл писать с нуля? На вряд ли. Но это помогает объяснить отношение к вэбу и невозможность принять другую точку зрения. Ютьюб большему не научит, да.

Не очень понял вопросов. Для таблиц базы данных шаблоны создают декларации (специальные структуры), они же автоматически создают слой функций (или классов в объектной модели) для работы с базой данных. Если под файловой системой подразумеваются какие-то абстрактные файлы, не файлы базы данных, то доступ можно организовать или тоже через декларацию, указав в ней тип драйвера ascii или dos, можно через win api. В программах на кларионе достаточно легко использовать напрямую win api или библиотеки на си. Документы такие же записи в базе данных, как в справочниках, со своим предопределенным набором некоторых полей. Или что имеется ввиду? С параллельным доступом на чтение или запись, и при использовании какой базы данных? Если topspeed, формат по умолчанию, то чтение параллельно, а при записи драйвер блокирует на короткое время других писателей. Битрив аналогично, хотя там есть и постраничные блокировки страниц, я ими не пользуюсь из-за соображений унификации. Кто использует sql, то он и в африке sql.

"Страшненькое" может не конструктор, а само UI в приложении. При желании можно включить манифест, будет менее страшненькое. А кому надо красивое, то можно использовать ActiveX со сторонними контролами, типа codejock. Одна фирмочка специализируется на имплементации этого добра. Если нужно, чтобы работало максимально быстро и стабильно, то проще всего страшненькую классику. Ну, я еще обои включаю и шрифт можно изменить в настройке приложения.

Ну, в чем-то все интернет магазины похожи. Разделы (кнопка на скриншоте) специфические - заказ по коду, по истории заказов, по последним поступлениям, по дефициту и т.п. Менеджер может создать персональное коммерческое предложение для покупателя, чтобы тот заказал товары прямо из него на сайте. Настраивается возможность заказа упаковками, сейчас еще лотки разного объема для кулинарии спрашивают. Такой готовой логики в стандартных магазинах не встречал. Главное же это связь с учетной системой. То есть это как-бы ее часть, а не само по себе. Скрипт в вебе крутится в необслуживаемом режиме, там только при запуске параметрическую настройку сделал, и все. Подключение пользователей в учетной системе, заказы прилетают операторам сразу в учетную систему, необходимая информация публикуется на сайте из учетной системы. Плюс аналилиз приходов, продаж, дефицита (заказывал, но не хватило), предпочтений, подписок и т.п. и рассылка соответствующих уведомлений тоже из учетной системы. В общем, там много чего под копотом.

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

Ну, т.е., ваше приложение - просто UI к БД. Логика тоже примитивная, наверное? Ну, описанная конфигами, а не кодом.

Я про физические документы. Способна ваша система сгенерировать из кучи записей в БД вордовский документ, а после сохранения его юзвверем, обратно его разобрать, и обновить записи в БД? А без строчки кода?

Не важно, как хранятся сущности. Важно как разрешаются конфликты, особенно те, что нарушают логику.
Ну, например, у сущности имеется дюжина свойств, и значение зависит от комбинации предыдущих десяти, некоторые из которых так же могут зависеть друг от друга, и состояния других сущностей, а могут не зависеть (опять-таки, в зависимости от их значений и комбинаций). Два пользователя одновремено открывают сущность в форме, чтобы внести изменения, и первый создаёт и сохраняет одну комбинацию, а второй - другую, которая не валидна при комбинации первого. Что произойдёт? Как это разруливается без кода?
Я лично предпочитаю простые сущности. Их и понять проще, и использовать надёжнее, и логика вся сконцентрирована в коде, а не размазана по проекту(ам). Но бизнес такой бизнес - иногда у него реально страшные хотелки. А если ещё и разрабов наберут по объявлению... там уже будет всё равно - десктопное у тебя приложение или вэб.

Ну, т.е., заточено под одну платформу, под одну ОС. Ставим минус. За ActiveX - ещё два минуса.

И всё же как оно - пользоваться хотя бы с гейпада удалённым доступом к рабочему столу и приложением, в котором кнопки и табы насованы буквально друг на друга?

OlegON, twix, интенсивные замеры длины "линеек" конечно весьма занятны и познавательны для себя "решил" и понял... не буду спорить:

1. Веб и интранет технологии наше "сейчас" и будущее, а десктопные приложения, пусть даже с костылями, доживают свой век;
2. На современном этапе для быстрого создания Веб приложений для бизнеса есть отличные фреймворки, языки разработки, СУБД;
3. Полезные, замкнутые системы автоматизации, ERP, WMS легко создаются, поддерживаются, устанавливаются малыми силами? Так убеждает twix и не согласны FinSoft, AndreyZh...

Остался "последний гвоздь"... Дайте ссылку в интернет на полезную, коммерческую, комплексную систему для бизнеса, хотя-бы на 50% решающие стандартные задачи таких систем, созданную и поддерживаемую "одиночкой" - дам фору: пусть это команда до 5 человек, реализованную почти полностью на Веб технологиях? Просто самоочевидно, что такие системы имеют сайты с описанием инструмента разработки и парадигму для бизнеса.