Плюсы и минусы автоматизации Excel с использованием VBA против .Net - PullRequest
13 голосов
/ 22 марта 2010

Мне было поручено создать инструмент финансового планирования в Excel, который бы использовал некоторые пользовательские функции / макросы.

Моя первая реакция была на использование VBA.Я использовал его для управления Excel раньше (скажем, 5 лет назад).Но затем я начал задаваться вопросом, было бы мне лучше использовать VSTO.

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

Ответы [ 5 ]

8 голосов
/ 22 марта 2010

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

Кроме того, VSTO не позволяет создавать пользовательские функции рабочего листа («UDF»), поэтому для этого вам потребуется внешний интерфейс VBA или создание управляемой надстройки COM без использования VSTO. Для сравнения, VBA позволяет создавать UDF практически без усилий.

Использование .NET имеет много преимуществ, в основном в отношении строгой типизации, полных возможностей ООП и возможности организации проектов более крупного размера. но VBA имеет огромные преимущества перед .NET, когда дело доходит до развертывания, что довольно сложно с Excel при работе с .NET или VSTO. VBA также является более простым языком для изучения и начала работы.

В целом, я бы посоветовал вам использовать VBA для повседневной разработки, но изучать VB.NET или C # на стороне, чтобы ваши навыки программирования могли расти за пределами Excel. В конце концов, ваши навыки .NET могут стать достаточно сильными, чтобы вы предпочли использовать его по сравнению с VBA, но для этого дня вам придется довольно хорошо разбираться в .NET.

(Другое аналогичное мнение по этому вопросу см. Потеряю ли я преимущества записи макросов при разработке приложений Excel в Visual Studio? .)

Редактировать: Обновление относительно комментария Энди, ниже:

Такие проблемы, как развертывание, отладка и UDF были те, которые я искал информацию для сравнения на. Судя по ответам на вопрос, который я должен был упомянуть, что У меня 5+ лет опыта работы с C #, тогда как мои навыки VBA (или не хватает из них) выходят только 3 или 4 раза в десятилетие

Хорошо, да, ты должен был сказать! Большинство людей с такими вопросами являются программистами VBA, которые хотят попасть в .NET. Так что я неправильно понял.

В вашем случае вам следует использовать C #, но я настоятельно рекомендую использовать C # 4.0 в Visual Studio 2010 для этого, это значительно улучшит синтаксис, который требуется при работе с объектной моделью COM, такой как Excel. VS 2010 в настоящее время находится в бета-версии 2, а дата RTM назначена на 12 апреля, так что мы почти на месте.

Что касается развертывания, с вашим опытом, я не думаю, что у вас будут слишком большие проблемы с установочными пакетами и т.п., и Visual Studio Tools for Office (VSTO) исключительно хорош для двух вещей:

  1. Создание пользовательского расположения ленты для надстройки с помощью дизайнера перетаскивания. Без дизайнера перетаскивания вы должны вместо этого предоставить XML. XML - это хорошо, если вы спросите меня, но дизайнер перетаскивания - это мечта использовать

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

К сожалению, VSTO доступен только для Excel 2003 и выше, и я думаю, что вам нужно создавать отдельные надстройки для Excel 2003 и Excel 2007. С другой стороны, можно создать управляемые надстройки COM, созданные без использования VSTO. совместимо с Excel 2000 и выше без труда. Наконец, VSTO не поддерживает создание UDF, и поэтому вам придется либо создать для этого надстройку управляемой автоматизации, либо использовать внешний интерфейс VBA, который вызывает ваши функции VSTO.

В целом, я бы пошел с VSTO, если вы можете ограничиться Excel 2007 и выше. Я хотел бы рассмотреть VSTO, если ваши требования для Excel 2003 и выше. И я бы пошел с управляемой надстройкой COM, если вам нужно иметь возможность работать в Excel версии 2000 и выше.

Для поддержки UDF я бы создал надстройку управляемой автоматизации, которая была бы жизнеспособна для Excel 2002 и выше. Если вам нужны пользовательские функции в Excel 2000 или ниже, тогда вам потребуется интерфейс VBA, который вызывает COM-видимые методы в вашей сборке .NET.

Это основные "за" и "против", как я понимаю. Дайте мне знать, если вам нужно знать больше.

- Майк

4 голосов
/ 13 января 2011

Учитывая ваше знакомство с C #, я бы порекомендовал вам взглянуть на Addin Express (стоимость) и Excel DNA (бесплатно), а также VSTO. Addin Express имеет независимую от версии PIA, которая упрощает развертывание, может обрабатывать как функции, так и команды, а также может использовать интерфейсы Automation и XLL (XLL намного быстрее, чем Automation). Excel DNA более оптимизирован для интерфейса XLL, но отлично подходит для разработки функций рабочего листа.

Отказ от ответственности: я не имею никакого отношения ни к Addin Express, ни к Excel ДНК

2 голосов
/ 22 марта 2010

Я не думаю, что в кодировании VBA в Excel есть что-то не так. Он имеет преимущество работы в пространстве процессов Excel, а взаимодействие VBA с объектной моделью Excels очень просто. Однако вам (и вашим пользователям) нужно действительно думать о своем инструменте как о надстройке Excel.

Если вы хотите, чтобы ваш инструмент отличался от идентификатора Excel, тогда Automation - ваш выбор. Это немного медленнее (вы «вне процесса»), и объектная модель немного менее чиста, но ваш инструмент будет иметь свою собственную идентичность.

(обратите внимание, что если вы используете C # и если у вас есть опция, используйте VS2010 и C # 4, есть ряд улучшений автоматизации, которые стоит обновить)

0 голосов
/ 08 августа 2011

Здесь много хороших ответов, поэтому я постараюсь подчеркнуть то, что еще не было сделано. Я бы придерживался VBA. Есть МНОГИЕ причины, но главными факторами для меня будут:

  • Не требует, чтобы на стороне клиента была указана вер. .Net установлен

Однако VBA, очевидно, не очень защищен, поэтому, если у вас есть код, который вы хотите скрыть, лучше всего использовать .Net, вероятно,.

0 голосов
/ 22 марта 2010

SpreadsheetGear для .NET позволяет добавлять совместимые с Excel компоненты электронных таблиц в приложения .NET (WinForms, ASP.NET и т. Д.) Без недостатков (производительность, простота использования) COM Interop.

Вы можете узнать больше об элементе управления SpreadsheetGear для Windows Forms здесь , посмотреть образцы ASP.NET здесь и загрузить бесплатную пробную версию здесь , если хотите Попробуйте сами.

Отказ от ответственности: я владею SpreadsheetGear LLC

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...