Архитектура Q - VBA Excel Macro или VS Инструменты для офиса?

Question

У меня есть требования от нашего клиента, где мы в основном должны «анализировать» PDF-файлы из разных источников.

Решение, с которым мы пришли, так как «фаза 1» (поскольку у нас мало времени для выхода на рынок и мы сэкономим им огромное количество времени), составляет

1) вручную используйте приложение Able2Extract, чтобы извлечь нужные столбцы из файла PDF и выплюнуть файл Excel. Этот файл Excel по-прежнему очень «грязный», так как содержит тонны информации заголовка, дополнительные поля, которые нам не нужны, и т. Д.

2) запустите наше приложение, загрузив в него этот файл Excel, который сделает оставшуюся часть очистки. Он берет этот «грязный» файл Excel, а затем дает им очень чистый файл Excel, в котором только 3 или 4 столбца, которые им нужны, все строки выстроены очень аккуратно.

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

Достаточно просто, а? На самом деле, нет. Этот скрипт работает только для одного конкретного типа файла из одного конкретного источника. У нас будет 10 различных источников, каждый с возможным 3-10 различными типами файлов. Это означает, что в итоге мы можем получить огромный макрос Excel, в котором есть 120 из этих очень специфических «скриптов очистки». Так что я беспокоюсь о долгосрочной ремонтопригодности здесь. Мы могли бы также натолкнуться на файлы, которые мы никогда раньше не видели, которые могли бы «сломать» наш скрипт очистки, и мне пришлось бы выполнить быструю повторную депиляцию / изменение сценария очистки ... Я никогда не использовал инструменты Visual Studio для Office и минимальный опыт работы с макросами VBA Excel - но здесь может показаться, что это хороший случай.

Какие-нибудь слова мудрости от кого-то, кто мог сделать что-то подобное раньше? Являются ли огромные макросы VBA чем-то вроде того, что может привести к кошмарам? Является ли VSTFO хорошей альтернативой, которая предоставит мне функциональность «легко перемещать / очищать данные», но с масштабируемостью и надежностью? Если честно; Моим первым инстинктом было чистое решение .NET с динамически скомпилированными сценариями, извлеченными из базы данных, с использованием нашего API Syncfusion Excel для очистки / очистки ... но, возможно, это излишне ..

Спасибо за любой совет ...

Answer 1

Во-первых, вам понадобятся программы очистки и удаления, не смотря ни на что. Дело в том, что Excel / VBA не намного хуже для поддержки этой функциональности, чем многие другие платформы.

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

Одна нефтяная компания заплатила мне, чтобы я написал приложение Excel, используя 4 пользовательские формы и более 5000 строк VBA в качестве инструмента, чтобы помочь своим бухгалтерам в составлении ежемесячной отчетности по совместным предприятиям. Приложение использовалось в течение 4 лет после окончания срока его службы, потому что интерфейс был настолько знаком и прост в использовании.

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

Answer 2

Я люблю программировать на C #, но ненавижу VSTO.

У меня есть две основные проблемы:.

• у вас больше нет прямого доступа к коду, все это компилируется в DLL, которая прикреплена к книге, без отладки на ходу (что может быть очень полезно для небольших кусочков RAD ). Отладка с помощью Visual Studio не является альтернативой возможности отладки в любом месте при использовании Excel VBA.

• вы используете интерфейс Excel VBA, обернутый для использования .NET, а не что-то, что кажется родным. У вас ужасные вызовы функций, такие как sheet.get_Range("A1:B1", System.Type.Missing); с отсутствующими на месте необязательными параметрами.

Есть много людей, которые используют VSTO, но, проведя много лет на платформе Excel VBA, я нашел несколько причин для перехода на этом этапе. Но подумайте, нужно ли вам делать довольно классные вещи в C # /. NET, которые вы не можете осуществить в VBA (например, рефлексия).

Вы можете написать очень хороший код на VBA; это вызывает много негативных отзывов, так как это среда, которая не наказывает вас за написание плохого кода, и абсолютно любой может побаловаться с VBA.

Это могут быть жалобы сварливого разработчика, имеющего опыт работы с VBA, а не с VSTO. Таким образом, сказав все это - если вы не знакомы с VBA, вам, возможно, будет лучше пойти прямо во VSTO. Я не уверен, что Microsoft намерена делать с VBA в будущем; ВСТО должно быть будущее.

Answer 3

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

Я бы сказал, пойти с VBA, и если вы беспокоитесь о удобстве обслуживания, подумайте о хранении «скриптов очистки» в отдельных файлах. Вы можете либо

(a) по одному файлу Excel на скрипт очистки, каждый с одним макросом с тем же именем; ваша надстройка может загрузить (и выполнить код) соответствующий файл Excel для любого входного файла

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

В обоих этих случаях вы можете хранить скрипты очистки в общей папке, чтобы иметь централизованное обновление, если вам нужно изменить скрипт.

Answer 4

Я считаю, что вы должны идти со своим первым инстинктом.

Хотя извлечение динамически скомпилированных скриптов из БД для меня определенно звучит излишне. Возможно, я не до конца понимаю вашу проблему, потому что не уверен, что проблема, связанная с извлечением динамически скомпилированных скриптов из БД, решается.

У вас есть Syncfusion Excel API для шага № 2, почему бы просто не написать чистое приложение .net, использующее Syncfusion для загрузки и управления файлами Excel и их повторного сохранения. Когда вы сталкиваетесь с новыми типами файлов для поддержки, вы обновляете приложение и перераспределяете его.

Это решение может занять немного больше времени, но:

1. Будет полностью в .NET (я ненавижу VBA).
2. Не будет использовать Excel в качестве серверного приложения (на что уже указал другой автор, это не то, для чего был создан Excel, и MS рекомендует не делать этого по причинам, указанным другим автором).
3. Будет (основываясь на моем опыте) выполнять на порядок быстрее, чем VSTO (взаимодействие) и, вероятно, VBA тоже.

Answer 5

Я бы не писал ничего, что требовало бы долгосрочного сопровождения в VBA, но если бы его краткосрочный VBA был бы в порядке.

С точки зрения производительности VBA немного быстрее, чем .NET, но вы теряете так много приятных функций, а новые версии VSTO, такие как отладка и полный доступ к OM, ушли в прошлое.

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

Если вы используете другие библиотеки, тогда используйте .NET - основная причина в том, что вы избавляетесь от 1/2 дюжины зависимостей библиотек, которые вам нужно будет добавить в VBA, таких как FSO, ADO, CDO и т. Д.

Другая распространенная жалоба, которую вы слышите, заключается в том, что вам нужно использовать метод доступа get из C # и что вы должны использовать Type.Missing alot.

С более новой версией .NET type.missing ушел в прошлое. Проблема с аксессором get была только в ранней версии библиотеки взаимодействия, и я думаю, что общее недопонимание использования объекта range и свойства range в C #.

Мне никогда не приходилось использовать методы доступа вообще, и как только вы напишете несколько методов-оболочек для обычных методов Excel OM, вам также не придется писать отсутствующие параметры вообще. Очевидно, в .NET 4.0 есть еще лучший способ решения этой проблемы.

Answer 6

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

Workbook("name").Sheets("name).Range(Cells(1,1),Cells(3,1)).Value = "Test"
Workbook("name").Sheets("name).Range(Cells(1,1),Cells(3,1)).Font.Bold = True
Workbook("name").Sheets("name).Range(Cells(1,1),Cells(3,1)).Font.Italics = True

Где это должно быть что-то вроде

With Workbook("name").Sheets("name).Range(Cells(1,1),Cells(3,1))
  .Value = "Test"
   With .Font
      .Bold = True
      .italics = True
   End With
End With

Оба будут делать то же самое, однако второй должен быть чуть лучше (возможно, есть лучшие примеры этого) и, по-моему, легче поддерживать.

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

Answer 7

Обращаясь к более широкому вопросу, вещи, которые необходимо учитывать:

1. VBA IDE поставляется с Excel. Не так просто с VSTO, если вы хотите, чтобы более широкая группа редактировала код.
2. На данном этапе больше людей знают, как писать на VBA, чем на VSTO.
3. Больше онлайн-поддержки VBA на данном этапе.
4. VBA не является чем-то большим, чем языком автоматизации для продуктов Office. Это вполне адекватно для этого и не будет уходить в ближайшее время. MS понимает, что это одна из вещей, которые Office имеет над OpenOffice - Кен из Учетных записей не собирается садиться с Eclipse и начинает печатать Public Static Void Main
5. Существуют значительные ограничения для VBA, если вы хотите начать использовать его как код приложения. Просто включение библиотек классов - это боль. Если это будет широко распространено, я бы пошел с VSTO.

Как сказано выше, постер: 5000 строк кода - это 5000 строк кода, дай или возьми.

Я не большой поклонник ВСТО. VBA работает для того, для чего он предназначен. Не нужно его переписывать. Если вам нужно получить жесткий код, используйте C #.

Answer 8

Если шаг 2 в конечном итоге должен стать услугой, и вы готовы потратить больше времени заранее (зависит от вашего графика поставки) и вы имеете дело с Excel в Open XML (хотя это возможно с также старые двоичные форматы) - ознакомьтесь с Open XML SDK и посмотрите на рекомендованную Microsoft серверную автоматизацию документов Office.

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

Answer 9

Может быть Excel Services для Microsoft Office SharePoint Server 2007/2010 может быть что-то? Похоже, что службы Excel нельзя использовать без SharePoint, хотя [ смотрите здесь ].

Службы Excel 2007 - Обзор

Службы Excel 2007 - Архитектура

Excel Services 2010 - Обзор

Службы Excel 2010 - Архитектура

Что такое Excel Services 2007?