Здесь нет реальных ответов от тех, кто демонстрирует большой опыт работы с Access, поэтому я дам свой ответ:
1. VBA даже предназначен для больших проектов?
Определите «большие проекты».В целом, я бы сказал, нет, но я думаю о приложениях для всего предприятия.Но вопрос здесь не в том, можно ли использовать VBA, а в том, является ли Access подходящим интерфейсом для приложений такого уровня.Самым большим недостатком Access (помимо проблем с развертыванием форм) является управление проектом, поскольку управление исходными кодами не так просто, как с другими платформами разработки.
Но вы на самом деле не представляете, насколько велико приложение.Используется ли это сотнями людей?Или это просто сотни подкомпонентов?То есть он большой с точки зрения сложности или большой с точки зрения количества пользователей?
Я думаю, что это более вероятно для макросов и просто функций, которые расширяют функциональность Access.
Как я уже сказал, вы задаете не тот вопрос.Вопрос в том, является ли Access подходящим интерфейсом.Если это так, то VBA - это язык, на котором вы должны писать его.
Что касается «макросов и простых функций», то существует терминологическая проблема в том, что Word и Excel «макросы» генерируются в VBA, что делает многолюди думают, что VBA - это простой язык.На самом деле VBA является СУПЕРСЕТОМ VB6 (не подмножеством) - в VBA встроено БОЛЬШЕ функциональных возможностей, чем в самом VB6.В Access большая часть этой функциональности специфична для взаимодействия с базами данных, и поэтому очень полезна (например, сравните форму, связанную с Access, с формой VB).
В общем, философия Accessэто тот, в котором вы начинаете строить объекты в интерактивном режиме, наводите и нажимаете, а затем добавляете код только тогда, когда поведения по умолчанию недостаточно.VBA обеспечивает большую гибкость, поскольку он может взаимодействовать с любыми инструментами, имеющими интерфейс COM.По сути, он неограничен в своих возможностях (хотя, конечно, есть предел тому, что практично).
2 Будет лучше конвертировать приложение в .NET winforms / wpf
«Лучше» для каких целей?Если у вас есть работающее приложение, вам действительно нужно учитывать эффект Spolsky / Netscape (упомянуто выше).Конечно, вы могли бы получить лучшее управление кодом, но за счет необходимости поддерживать его гораздо больше.С другой стороны, если у вас есть собственный опыт работы с этой платформой разработки и нет опыта работы с VBA, то будет существовать тенденция к переходу на платформу разработки, которая больше подходит для ваших конкретных разработчиков.
Но это не совсем так.проблема «лучше», которая не может быть решена без знания всех проблем и вовлеченного персонала.
3 Может ли больше разработчиков работать над проектом VBA?
Visual SourceSafe позволяет нескольким разработчикам работать над проектом.Или вы можете автоматизировать сборку с помощью Application.SaveAsText / .LoadFromText и использовать выбранный вами CVS.
Но в целом я бы сказал, что Access гораздо лучше подходит для модели с одним разработчиком.
4 Какие наихудшие недостатки кода VBA, выполняемого в хостинговой программе по сравнению с автономным приложением?
Понятия не имею, что означает этот вопрос.У многих людей есть сумасшедшая идея, что рабочий набор для внешнего интерфейса Access больше, чем рабочий набор для приложения VB6, делающего то же самое, но на самом деле это не так.Я ожидаю, что .NET примерно такой же (если не еще больший рабочий набор, так как вещи всегда становятся все больше и больше по мере продвижения вперед).
Самым большим недостатком Access, по моему мнению, является проблема развертывания, когда у любого пользователя, которому требуется несколько версий Access, может быть много проблем. Сценарии установки SageKey предназначены для исправления этой проблемы, но они являются специальными - они исправляют проблемы при их появлении, поэтому, если у вас есть среда развертывания с проблемами, с которыми они еще не сталкивались и не обрабатывались, вы выходите из удачи. Но они охватывают большинство таких обстоятельств.
5 Возможно ли запускать юнит-тесты или какую-либо подобную технологию?
Я не верю в это, но тогда, как разработчик Access, я, вероятно, не имею ни малейшего представления о том, что такое юнит-тестирование. Большая часть кода приложения Access - это пользовательский интерфейс, а не алгоритмическое программирование, поэтому я не думаю, что это будет легко тестируемым. Является ли это проблемой или нет, зависит от характера проекта и типа тестирования, которое считается необходимым.
Для приложения бухгалтерского учета вам действительно требуется высокий уровень надежности, и, как я уже сказал в комментарии в другом месте, если бы кто-то брал у меня интервью для потенциального проекта по созданию приложения бухгалтерского учета, я бы порекомендовал, чтобы они не создавали его из царапина, независимо от выбранной платформы.