Опыт с “преобразователями языка”?

Мне кажется, как есть почти всегда бывает с вопросами MS-ACCESS, имеющими теги, которые привлекают более широкую аудиторию StackOverflow, и люди, отвечающие на вопросы, пропускают ключевой вопрос, который я читал как:

Существуют ли какие-либо инструменты, которые могут успешно преобразовать приложение Access в любое другая платформа?

И ответ

АБСОЛЮТНО НЕ

Причина в том, что в инструментах того же семейства, которые используют аналогичные модели для объектов пользовательского интерфейса (например, VB6), не хватает многих вещей, которые предоставляет Access по умолчанию (как преобразовать непрерывную подчиненную форму Access в VB6 и не потерять функциональность?). А другие платформы даже не используют ту же базовую модель, что и VB6 и Access, поэтому им приходится преодолевать еще больше препятствий.

Процитированная статья о MySQL довольно интересна, но она действительно сбивает с толку проблемы, связанные с некомпетентно разработанными приложениями, и проблемами, связанными с используемыми инструментами разработки. Плохая схема данных не присуща Access - она ​​присуща [большинству] начинающих пользователей баз данных. Но статьи, похоже, приписывают эту проблему Access.

И полностью игнорирует возможность исправления схемы, увеличения ее размера до MySQL и сохранения внешнего интерфейса в Access, что на сегодняшний день является самым простым подходом к решению проблемы.

Это именно то, что я ожидаю от людей, которые просто не получают Access - они даже не считают, что Access как интерфейс к защищаемой серверной СУБД большой емкости может быть превосходным решением проблемы.

В этой статье даже не рассматривается преобразование приложения Access, и для этого есть веская причина. Все инструменты, которые я видел, утверждают, что конвертируют приложения Access (на любую платформу), либо конвертируют ничего, кроме данных (в этом случае они вообще не конвертируют приложение - идиоты!), Либо рабски преобразуют интерфейсную структуру. , с соответствием 1: 1 между объектами пользовательского интерфейса в приложении Access и в целевом приложении.

Это не работает.

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

Во-вторых, когда мы думаем о преобразовании приложения Access для развертывания в веб-браузере, вся модель приложения будет другой, то есть от состояния к состоянию без состояния, и поэтому дело не только в нескольких неподдерживаемых функциях Access,но совершенно другой фундаментальной модели того, как объекты пользовательского интерфейса взаимодействуют с данными. Возможно, приложение со 100% несвязанным доступом можно относительно легко преобразовать в реализацию на основе браузера, но сколько их там? Это будет означать приложение Access, которое не использует никаких подчиненных форм (поскольку они не могут быть отвязаны), и приложение, которое использует только несколько событий из богатой модели событий (большинство из которых работают только с привязанными формами / элементами управления). Короче говоря, 100% несвязанное приложение Access будет тем, что борется со всей парадигмой разработки Access. Любой, кто думает, что хочет создать несвязанное приложение в Access, действительно не должен использовать Access в первую очередь, поскольку вся суть Access - это связанные формы / элементы управления! Если вы устраните это, вы выбросите большую часть преимуществ RAD в Access над другими платформами разработки и почти ничего не получите взамен (кроме огромной сложности кода).

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

Конечно, все это меняется в Access 2010 и Sharepoint Server 2010 со службами Access. В этом случае вы можете создать свое приложение в Access (используя веб-объекты) и развернуть его в Sharepoint, чтобы пользователи могли запускать его в браузере.Результаты функционально на 100% эквивалентны (и на 90% визуально) и выполняются во всех браузерах (здесь нет зависимостей, специфичных для IE).

Итак, начиная с июня этого года самым дешевым способом преобразования приложения Access для развертывания в браузере вполне может быть обновление до A2010, преобразование дизайна для использования всех веб-объектов и последующее развертывание с помощью Sharepoint. Это нетривиальный проект, поскольку веб-объекты Access имеют ограниченный набор функций по сравнению с клиентскими объектами (и, например, без VBA, поэтому вам нужно изучить новые макросы, которые намного мощнее и безопаснее старых, так что это не та ужасная трудность, которая может показаться тем, кто знаком с устаревшими макросами Access), но, вероятно, это будет намного меньше работы, чем полномасштабный редизайн для развертывания в Интернете.

Другое дело, что это не потребует переобучения для конечных пользователей (поскольку версия веб-объекта такая же, как и исходная версия клиента), так как в клиенте Access она будет такой же, как и в Интернете. браузер.

Короче говоря, я бы сказал, что преобразование - это химера, и почти всегда не стоит затраченных усилий. Фактически, я согласен с процитированным мнением (даже если у меня много проблем с другими комментариями из этого источника). Но я также предупреждаю, что стремление к конверсии часто бывает ошибочным и упускает из виду более дешевые, простые и лучшие решения, которые не требуют полной замены приложения Access сверху вниз. Очень часто неудовлетворенность Jet / ACE как хранилищем данных сбивает людей с толку и заставляет думать, что они также должны заменить приложение Access.И это правда, что многие приложения Access, разработанные пользователями, содержат ужасные, неразрешимые компромиссы и удерживаются вместе с помощью жевательной резинки и проволоки. Но плохо спроектированное приложение Access можно улучшить в сочетании с увеличением размера серверной части и пересмотром схемы данных - от этого не нужно отказываться.

Это не значит, что это легко - очень часто это не так. Как я все время говорю клиентам, обычно легче построить новый дом, чем реконструировать старый. Но одна из причин, по которой мы реконструируем старые дома, заключается в том, что они обладают незаменимыми характеристиками, которые мы не хотим терять. Очень часто приложение Access неявно включает в себя множество бизнес-правил и моделирования рабочих процессов, которые не должны быть потеряны в новом приложении (старая загадка Netscape, по словам Джоэла Спольски). Эти вещи могут быть не очевидны для внешнего разработчика, пытающегося выполнить перенос на другую платформу, но для конечного пользователя, если приложение дает результаты, которые на копейку ниже, чем у старого приложения, они будут недовольны (и, вероятно, должно быть, поскольку это может означать, что другие аспекты приложения также не дают надежных результатов).

Как бы то ни было, я слишком долго бредил, но считаю, что преобразование никогда не работает, за исключением самых тривиальных приложений (или тех, которые были разработаны для преобразования, например, приложение со 100% несвязанным доступом). Я за доработку вместо замены.

Но, конечно, этим я зарабатываю на жизнь, то есть чиню приложения Access.