Расширяемость MS Word: макрос VBA против .Net VSTO? - PullRequest
5 голосов
/ 03 октября 2011

Один из моих клиентов попросил нас разработать «макрос VBA». Однако в 2010-х годах мне кажется странным использовать такой устаревший язык, и я думаю о том, чтобы убедить клиента использовать вместо этого VSTO dev. Однако, поскольку я новичок в обоих мирах, мне нужна помощь, чтобы заполнить страницу за / против, чтобы иметь возможность утверждать это.

Конечно, ответ не может прийти без фактического требования, позвольте мне попытаться возобновить:

Цель: Word 2003/2007 (но я подозреваю 2010 год как еще не известное требование) edit Требование 2010 подтверждено

Для внешней системы публикации требуется .doc файл в качестве входных данных. В файле .doc должны быть применены определенные стили: «Пользовательский заголовок 1», «Пользовательский заголовок 2» и т. Д.

Пользователь может создавать документы, используя Word, двумя возможными способами:

  1. Запустите новый документ, используя файл .dot, развернутый на компьютере
  2. Преобразование любого существующего документа в соответствие целевому шаблону

Пользователи могут «применять» стили «просто» (простой пользовательский интерфейс): контекстное меню, меню стилей, панель пользовательских действий и т. Д.

К настоящему времени я вижу следующие плюсы и минусы:

  1. * 1033 VBA *

    • Плюсы:
      • быстрое и грязное развитие (быстрая часть предложения)
      • У заказчика уже есть какой-то макрос производства
    • Минусы:
      • трудно найти опытного разработчика
      • быстрое и грязное развитие (грязная часть предложения)
  2. VSTO

    • Плюсы:
      • преимущества языка .Net (скомпилированный, типизированный, строгий, библиотека классов и т. Д.)
      • модель безопасности более гибкая и мощная (доверяющий код подписан доверенным органом)
      • возможен мост к панелям WPF
      • Вы работаете в Visual Studio и имеете доступ к ее полному набору функций: рефакторинг, контроль исходного кода и т. Д.
    • Минусы:
      • требует установки .Net framework (вероятно, не проблема сегодня) и VSTO runtime
      • труднее развернуть
      • немного больше работы на старте (но меньше в долгосрочной перспективе)

Ответы [ 5 ]

3 голосов
/ 03 октября 2011

Я недостаточно знаком с .NET, но вот мое скромное мнение о VBA:

* VBA 1004 *

  • Плюсы:
    • легко развернуть и заставить его работать с приложениями Office
    • быстрое и грязное развитие (быстрая часть предложения) - согласовано
  • Минусы:
    • трудно найти опытного разработчика
    • трудно выбрать опытного разработчика и объяснить своему клиенту, что ему нужно инвестировать в этот навык
    • быстрое и грязное развитие (грязная часть предложения) - частичное согласие. Будет грязно, если:
      • вы даете проект начинающему VBA и не подставляете его / ее
      • ваш проект становится слишком большим с точки зрения требований
    • требует наличия .Net Framework (вероятно, не проблема сегодня) Я так не думаю (может быть, CONS VSTO?)

Я бы сказал, что если вам нужен только какой-нибудь код или надстройка для объединения нескольких файлов, вы можете легко сделать это с VBA , и он не будет грязным (если вы действительно не хотите к).

2 голосов
/ 09 ноября 2011

Я отвечаю себе на вопрос, когда проект закончен.

Я наконец решил написать приложение, используя макрос VBA.Вот посмертное заключение этого выбора:

Плюсы:

  1. Команда, которая будет поддерживать приложение, не имеет знания C #, только VBA (основная причина моего выбора).
  2. Плохая модель безопасности: это профессионал, потому что нет других настроек, которые бы помещали файлы в нужное место.
  3. Нет предварительных условий выполнения

Минусы:

  1. Развертывание должно было быть простым.
    • Я рассчитывал на возможность поиграть с опциями Word «Каталог пользовательских шаблонов» и «Каталог шаблонов запуска».Но это было невозможно, потому что приложение не связано с конкретным объектом в организации клиента.Мне не разрешили «взять на себя ответственность» за эти настройки для этого приложения.
    • Я закончил писать собственный скрипт NSIS для развертывания приложения в правильных папках.С VSTO, простой проект установки (clickonce?) Сделал бы эту работу.
  2. Язык настолько доисторический!Индекс коллекций начинается с 1, массив до 0, нет ООП, плохой готовый язык и библиотека.Это не всегда проблема, но в моем случае моделирование бизнес-правила было немного болезненным (представление иерархических данных в дереве было непростой задачей)
  3. Очень ограниченная интеграция с контролем исходного кода (код, так каквстраивается в файлы .dot, не поддерживается в истории. Только полный файл .dot был)
  4. Управление ошибками очень ограничено с VBA
  5. Плохая IDE

Примечание:

Как опытный разработчик C #, плюсы / минусы могут быть немного неравнодушными.

1 голос
/ 02 января 2012

В этой статье я попытался обобщить похожие вопросы в контексте Excel. Те же аргументы применимы ко всем приложениям Office, включая word.

1 голос
/ 04 октября 2011

Я большой разработчик VBA для Excel.

VBA pro: Одно из главных препятствий для меня, когда я переключаюсь на VSTO с VBA - и, поверьте мне, я люблю кодирование на C #, - это отсутствие отладки на лету, к которой привыкла моя база пользователей. Я часто прыгаю прямо в проблему VBA на ПК пользователя, как это происходит, но с VSTO это невозможно. (Если кто-то не может исправить меня.)

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

VBA con: VBA - это один из тех языков, с которыми легко играть и, следовательно, легко создавать путаницу. Он не применяет принципы «чистого кодирования», а это означает, что в то время как приличные программисты могут создавать из них великолепные приложения, VBA может ассоциироваться с хакерствами и растягиванием органического кода из-за низкого уровня доступа. По этой причине разработчиков VBA часто считают более низким классом разработчиков, когда действительно не удается провести различие между теми, кто использует его с умом, и теми, кто этого не делает.

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

(Я склонен видеть Perl в том же свете; отлично подходит для коротких сценариев, но когда кто-то, привыкший использовать для написания сценариев, начинает использовать его для большой работы - вы, как правило, получаете что-то немного громоздкое.)

0 голосов
/ 22 июля 2015

Согласно моим наблюдениям: VSTO: CONS: если мы разработали контроль над лентами Addins для Word 2007, мы можем развертывать только с Word 2007, но мы не можем развертывать с Word 2010 или Word 2013. Для меня это главный недостатокразработать дополнения для word и excel для всех его версий, таких как 2007, 2010 и 2013 годы. Пожалуйста, исправьте меня, если я ошибаюсь, или предложите мне, как я могу разработать отдельные дополнения для всех офисных версий.

...