Biuro w studiu

Microsoft Office, a wcześniej programy Word i Excel, były dla wielu pierwszym ''narzędziem programistycznym''. Wraz z rozwojem tych aplikacji sposób programowania makr i rozszerzeń stawał się coraz bardziej ujednolicony aż wyewoluował w Visual Basic for Applications. Teraz dzięki VSTO Office'a można programować w językach .NET.

Microsoft Office, a wcześniej programy Word i Excel, były dla wielu pierwszym ''narzędziem programistycznym''. Wraz z rozwojem tych aplikacji sposób programowania makr i rozszerzeń stawał się coraz bardziej ujednolicony aż wyewoluował w Visual Basic for Applications. Teraz dzięki VSTO Office'a można programować w językach .NET.

Rozwiązania oparte na Microsoft Office mają sporo zalet. Po pierwsze - użytkownik pracuje z pakietem o dobrze znanym interfejsie. Także programista wiele standardowych elementów interfejsu użytkownika ma dostępnych automatycznie (choć trzeba pamiętać, że nie może osiągnąć takiego bogatego UI, jak w samodzielnych pakietach IDE). A co najważniejsze - dzięki oparciu rozwiązania na Office, bardzo bogatej, gotowej platformie aplikacyjnej powstaje ono błyskawicznie i pozornie nie wymaga od programisty dużej wiedzy. I często właśnie szybkość tworzenia rozwiązania biznesowego i późniejsza łatwość obsługi sprawiała, że przymykano oczy na niezbyt profesjonalną strukturę takich aplikacji. One po prostu działają.

Typy projektów w VSTO 2005.

Typy projektów w VSTO 2005.

Jednak nie jest to rozwiązanie cudowne. Pierwsza i największa wada związana jest z samym modelem programowania, w którym dane i aplikacja są ściśle powiązane ze sobą (a de facto - "siedzą" w jednym szablonie/dokumencie). Tworzenie pomocniczych bibliotek, próby oddzielania danych (tworzenia warstw pośrednich) - konstrukcje stosunkowo proste w innych środowiskach, w VBA wymagały wielu trików programistycznych. W rezultacie z czasem rozwiązanie VBA, zwłaszcza napisane przez początkującego programistę, stawało się coraz bardziej kłopotliwe w utrzymaniu (czyli np. wprowadzaniu kolejnych poprawek).

Drugi problem wynika z tego, że "pod spodem" jest pakiet biurowy - o określonej skalowalności i wydajności. Pojawiają się także problemy, gdy chcemy np. umieścić rozwiązanie na serwerze i zapewnić równoległy dostęp wielu użytkownikom czy generalnie - synchronizować zmiany.

Microsoft w 2003 roku opracował pierwszą wersję Visual Studio Tools For Office - pakietu, który pozwala pisać aplikacje oparte na Office z wykorzystaniem .NET. Także do VS 2005 jest taki pakiet, w którym (w dużym skrócie) wiele elementów dopracowano, a dodatkowo pojawiły się nowe możliwości: obsługa tagów inteligentnych, współpraca z Project Server, lepsza obsługa dodatków do Outlooka, mechanizmy pozwalające na przetwarzanie po stronie serwera, buforowanie danych i wiele, wiele innych.

Edycje i instalacja

VSTO 2005 jest oferowane z edycją Visual Studio 2005 Professional i następnymi wersjami; jest też oddzielny produkt o tej nazwie. W kolejnej wersji Office (12) będą działać dodatki z VSTO 2005 - jednak aby być w zgodzie z nowym interfejsem użytkownika, twórcy dodatków będą mogli dodatkowo określić sposób interakcji z użytkownikiem.

Aby móc korzystać z VSTO, trzeba zainstalować odpowiednie składniki Office 2003 i dodatek SP 2 (od niedawna w polskiej wersji). Nie można np. tworzyć rozwiązania do Microsoft Project, nie instalując tego pakietu, ale jeśli ktoś chce pisać dodatki do Worda, nie potrzebuje Excela.

Aplikacja pisana w VSTO korzysta z PIA, czyli komponentów .NET obudowujących obiekty COM Office'a. Z tego powodu w kilku miejscach wygodniej mieć język bez mocnej kontroli typów i warto się zastanowić, czy VB.NET nie będzie lepszy. Tworząc aplikacje, trzeba mało restrykcyjnie ustawić uprawnienia w Office, aby kod mógł działać. Czasami także przeszkadzają zbyt "inteligentne" skanery antywirusowe (lepiej je wyłączyć albo zablokować monitorowanie rozwiązań Office). I zawsze po przetestowaniu rozwiązania na maszynie deweloperskiej warto sprawdzić, czy działa w innym komputerze.

Możliwości VSTO

Definicja obiektu DataSet dla "inteligentnego" wzorca.

Definicja obiektu DataSet dla "inteligentnego" wzorca.

W VSTO 2005 mamy kilka typów projektów (ich lista zależy od zainstalowanych pakietów z rodziny Office): do Excela (skoroszyt i wzorzec), do Worda i dodatek do Outlooka (niedostępny w wersji beta 2, wymaga RTM). Można także tworzyć rozwiązania do InfoPath 2003 czy Project Server. Warto dodać, że nie ma dużych różnic między szablonem a dokumentem (jedyna polega na kolejności zgłaszanych zdarzeń).

Piszemy program w .NET - mamy dostęp do ADO.NET, wszystkich usług platformy (w tym usług WWW), dobry debuger - wszystko to, co zawiera Visual Studio 2005. Ale projektując interfejs, dodając przyciski czy dostosowując menu, pracujemy na dokumencie Office'a. Obszar projektanta to Excel lub Word, tyle że osadzony w IDE. Można na nim umieszczać kontrolki Windows Forms, tworzyć dodatkowe formularze. Pojawiają się także nowe typy składowych projektów - np. do tworzenia tzw. Action Pane (okien obok dokumentu, w których np. w Wordzie widać style czy formatowanie akapitów).

Wszystkie te elementy składają się na tzw. inteligentny dokument (Smart Document) - nową koncepcję, gdzie oprócz treści z dokumentem związana jest pewna logika.

Proszę sobie wyobrazić raport będący de facto arkuszem Excela, który automatycznie pobiera dane z różnych źródeł, przelicza je w sposób niedostępny dla formuł Excela oraz pozwala użytkownikowi na proste "sprawdź, co będzie, gdy..." - czyli np. zmianę wartości bazowych i obserwację, jak zmieniają się wyliczone wskaźniki. A dodatkowo w takim arkuszu umieszczony jest przycisk Publikuj - jego naciśnięcie spowoduje, że wyniki analiz zostaną wysłane do portalu i opublikowane (albo posłużą do dalszych obliczeń). To wszystko dzięki VSTO jest stosunkowo proste, Office staje się dodatkowym zasobem, z którego może korzystać aplikacja .NET.

Wiele osób zada sobie pytanie: kiedy warto sięgnąć po VSTO, a kiedy wystarczy Visual Basic for Applications? Trzeba podkreślić, że te narzędzia mają inne zastosowania (i grupy użytkowników). VBA to głównie język makr - automatyzacji, gdy trzeba np. wielokrotnie wykonać jakąś operację, utworzyć szablon układu, w którym szybko wybierzemy opcje formatowania itp. Jeżeli natomiast projektujemy okna dialogowe (kreatory), musimy się komunikować z różnymi źródłami danych, "towarzyszyć" użytkownikowi w czasie pisania dokumentu (i np. coś mu podpowiadać) - wtedy pisanie (a zwłaszcza konserwacja!) w VBA będzie znacznie trudniejsza niż w VSTO.

Warto też podkreślić, że z poziomu VSTO mamy dostęp do pełnego modelu obiektowego Office, a więc także do mechanizmów automatyzacji, tych samych, co w makrach VBA. Nie można jednoznacznie wskazać, co jest niemożliwe do zrealizowania w VBA czy VSTO - natomiast pewne rzeczy się robi prościej w jednym z nich.

Podstawy

Zaprojektowana aplikacja w IDE VS.NET.

Zaprojektowana aplikacja w IDE VS.NET.

Jednym z większych zarzutów wobec VBA wykorzystujących Worda i Excela jest to, że składniki aplikacji - kod, dane, sposób prezentacji - są razem, w jednym pojemniku, bez żadnej separacji itp. Jeżeli programista chce się odwołać do jakiegoś pola w dokumencie Office, to musi napisać:

Application.Worksheets("Skoroszyt1").

Cells(2, 2).Value = 2

czyli w tym wypadku jawnie wskazać komórkę arkusza. Jeżeli w trakcie formatowania zostaną dodane jakieś wiersze czy kolumny, to pojawi się duży problem - trzeba przeanalizować kod, aby wykryć, gdzie wprowadzić modyfikację. Nazwane obszary czy zakładki trochę to ułatwiają, ale nie rozwiązują problemu (użytkownik może je zbyt łatwo ręcznie usunąć).

W VSTO wprowadzono mechanizm, który w dużym stopniu izoluje kod od "układu" SmartDoc. Wprowadzona została koncepcja widoku i kontrolki widoku (view control).


Zobacz również