Есть ли веская причина продолжать писать приложения VBA + Access Forms? - PullRequest
1 голос
/ 12 февраля 2010

Меня недавно попросили обновить старое приложение форм доступа. Исходя из .NET фона, я нашел изменения пугающими, и мне стало немного неловко. Я предполагал, что это устаревшие технологии, быстро превращающиеся в анахронизмы ...

Я не прав? Если да, то каковы причины для продолжения использования этой технологии (кроме того, чтобы избежать затрат на перенос старых приложений на .NET)?

Ответы [ 4 ]

28 голосов
/ 12 февраля 2010

Вместо ответа на подтекст вопроса (а именно, что приложения Access ужасны, несмотря ни на что), я дам некоторую информацию о будущем Access:

  1. Access является флагманским продуктом для Microsoft. Его нельзя заменить в линейке продуктов Microsoft, поэтому он будет продолжать продвигаться и развиваться Microsoft в той или иной форме в обозримом будущем (до тех пор, пока есть пакет Office от MS, будет Access).

  2. За пределами MS практически нет конкуренции за функциональность, которую обеспечивает Access. Единственный сопоставимый продукт в любом месте - FileMaker Pro. Можно было бы сказать, что базовый компонент в пакете OpenOffice является конкурентным, но он охватывает только подмножество функций, предлагаемых FM и Access (что не означает, что его может быть недостаточно для любого количества сценариев).

  3. Access (и весь пакет Office) по-прежнему использует VBA в качестве языка программирования, а остальная часть Microsoft перешла с VB на языки на основе .NET. Другие продукты Office теперь могут использовать компоненты .NET (хотя и не так, как они используют VBA), но это не относится к Access. Я ожидаю, что когда-нибудь в следующих нескольких версиях Access (, а не в A2010) поддержка .NET будет каким-то образом введена. Но, зная историю MS, VBA будет по-прежнему поддерживаться для нескольких версий.

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

  5. Ядро базы данных Jet было объявлено MS практически мертвым во время выпуска Jet 4 (выпущенного в 1999 году), даже несмотря на то, что MS сделала Jet 4 компонентом операционной системы Windows (и до сих пор так и есть). Jet получил новую жизнь с выпуском Access 2007 и включением новой версии ядра базы данных Jet под названием ACE, принадлежащей команде разработчиков Access (Jet 4 по-прежнему принадлежит команде разработчиков Windows и заморожен как есть , без дополнительного развития). Большая часть новой функциональности, представленной в ACE, была продиктована целью Microsoft по интеграции Access с Sharepoint, но с A2010 некоторые из новых функций (например, макросы данных на уровне таблицы, которые обеспечивают эквивалент триггеров) очень полезны даже без используя Sharepoint (другие, как многозначные поля, нет). В 64-разрядной версии Office появилась 64-разрядная версия ACE, поэтому Jet / ACE теперь можно использовать в 64-разрядных приложениях без необходимости компиляции только как 32-разрядных.

Теперь последний вопрос:

@ ChrisDiRulli спросил:

Есть ли основания продолжать использовать эта технология (кроме того, чтобы избежать стоит переместить это)?

Конечно, есть очень веские причины продолжать использовать Access:

  1. приложение уже разработано.

  2. приложение работает или работает достаточно хорошо, чтобы выполнить работу.

  3. приложению нужны только некоторые новые функции, а не полное переписывание.

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

У Access большое будущее, мне кажется. Я не был в восторге от Access с момента выпуска Office 95/97, который представил VBA в пакете Office и позволил создавать «мета-приложения», построенные поверх пакета Office.

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

Если проблема в том, что ни у кого нет возможности (или интереса) спасти приложение, вам следует подумать о найме подрядчика, который является опытным разработчиком Access. Найти этих людей не так просто, но их там много. Вы можете определить, кто является компетентным, по их публичным публикациям в группах Access Usenet и даже по некоторым из них здесь, на SO.

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

Но обо всем по порядку:

Потерять враждебность к Access. Это иррационально и на 99,99% вероятно, что оно полностью основано на невежестве.

9 голосов
/ 12 февраля 2010

Существует еще тонна программного обеспечения, написанного на языке COBOL, и это намного старше, чем Access.

В некоторых областях приложение Access, вероятно, является достаточным и наименее дорогим вариантом. Если он выполняет свою работу (ваша задача частично - сообщить вашему работодателю, если он действительно выполнит работу) и если это то, чего они хотят, то сделайте это.

Если вы видите веские причины, по которым проект .NET будет лучше или что Access потерпит неудачу, обсудите их открыто и постарайтесь найти решение, которое наилучшим образом отвечает интересующему вас лицу.

4 голосов
/ 12 февраля 2010

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

Вы были разочарованы, что все разработчики проходят. Я никогда не начинаю свой день с мысли: « & ^% &, мне нужно создать новое приложение! Когда я смогу вернуться к 3-летнему .NET-коду и исправить это ... «Рефакторинг имеет свое место.

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

3 голосов
/ 13 февраля 2010

Используйте правильные инструменты для правильной работы. Многим людям в ИТ отказывают в доступе из-за необходимости поддерживать какую-то ужасную базу данных, сделанную кем-то, только выходящим из Excel. Однако доступ имеет много вещей для этого. Например, у меня готовится проект, который требует быстрого развертывания около 10 пользователей с небольшим перерывом во времени. Для этой работы я оставляю сервер SQL и копию Visual Studio на полке и использую доступ. Если доступ подходит для работы, зачем переписывать его в .net, чтобы он мог быть в .net. Для меня используемый инструмент программирования - это средство для достижения цели, а не особенность

...