19 sierpnia 2011

12 zasad kulturalnego programisty SharePoint'a (Część II - EOM)

Zasad cdn-astąpił


W poprzednim poście opisałem jak "kulturalny" programista SharePoint'a powinien obchodzić się z feature'ami. Tym razem postaram się opisać kolejne 8 zasad dotyczących WebPartów, Event Reciever'ów, zarządzania zasobami serwera oraz ogólną "czystością" środowiska.

WebPart


Przychodzi taki moment w projekcie, że klientowi nie podoba się dany Webpart i chciałby go usunąć ze swojego portfolio (Wepart Gallery). Usłużny programista usuwa niepotrzbną klasę webparta i wrzuca nową wersję biblioteki na serwer produkcyjny. Problemy, które mogą wyniknąć z takiego podejścia opisuję w postach  Test-SPContentDatabase and how to locate MissingWebPart oraz SPLimitedWebPartManager and ErrorWebPart on and off relationship, polecam też KB976218. Użytkownicy zostają z ErrorWebPart'ami wyświetlonymi na stronie i  pozostaje im tylko WebPart'owe sepuku.  Zatem zasadar nr. 5.

Klasa WebPart'a może zostać usunięta po zlikwidowaniu wszystkich instancji Webpart'a znajdujących się na farmie.  



Inną przypadłością deinstalacji WebPart'ów jest pozostawianie plików .dwp w WebPart gallery. Pliki te po usunięciu z katalogu SharePoint'a (12-tki lub 14-tki) pliku dwp oraz biblioteki zawierającej klasę WebPart'a zaśmiecają galerię WebPart'ów. Zatem zasada nr. 6

Proces odinstalowania Webpart'a powinien zawierać usuwanie pliku dwp z WebPart Gallery.  

Biblioteka zawierająca klasę WebPart'a musi być podpisana kluczem (strongly-signed) aby jednoznacznie określić wersję danego dll'a. W momencie gdy programista postanowi podbić wersję biblioteki (np. z 1.0.0.0 do 1.1.0.0) wpłynie to na istniejące instancje WebPart'a. Należy wtedy dodać assembly binding redirection do web.config'a i "przekierować" wszystkie instniejące instancje ze starszej wersji na nową oraz dodać nowy wiersz do SafeControls dla 1.1.0.0 i utrzymać stary dla wersji 1.0.0.0. Jest to potrzebne do momentu wyświetlenia przez UI po raz pierwszy instacji WebPart'a, od tego momentu korzysta on z wersji 1.1.0.0. Po pewnym czasie można zatem usunąć   SafeControls dla 1.0.0.0, oczywiście jeżeli wszystkie WebParty zostały wyświetlone. Uwaga na boku, bug (opisany  tutaj) związany z Assembly BindingRedirect element (solution manifest.xml) został naprawiony dopiero w June CU 2011 dla SharePoint'a 2010.  Zatem zasada nr. 7  

Nowe wersje biblioteki WebPart'a muszą być obsłużone przez wpisy BindingRedirect w Web.config'u


Event Receiver


System wymaga ciągłych zmian, nasze feature'y rejestrują najdziwniejsze event receivery. Instalujemy komponenty od zewnętrznych dostawców, one też dodają event receivery aby obsługiwać możliwie najwięcej zdarzeń. OK, a jeżli nie jest już nam potrzebny dany Event Receiver, to trzeba go odpiąć od każdego zarejestrowanego zdarzenia, i kropka ( a jak nie to znowu  KB976218). Zasada nr 8.

Klasę Event Receiver'a można usunąć  tylko po odrejestrowaniu wszystkich referencji do obsługiwanych zdarzeń. 

Rozmaitości


W developmencie SharePoint'a zmiany trzeba dobrze zaplanować i przetestować. Szczególnie jeżeli nadgorliwy programista chce przeprowadzić intensywny "refactoring", aby naprawić całe zło tego świata. Zmiany nazw feature'ów, katalogów, plików, assembly, zmiany wersji assembly, usuwanie elementów, to przykłady refactoringu który może rzucić cię na kolana, jeżeli nie zrobisz tego prawidłowo. Na pocieszenie mogę powiedzieć, że SharePoint 2010 oferuje mechanizmy do np. przenoszenia plików w obrębie katalogu 14\Template\Features\ (patrz MapFile) w ramach upgrade'u instancji feature'a. Zasada nr 9.

Z refactoringiem w SharePoint jak z ogniem, czyli ostrożnie.


Kolejnym wdzięcznym tematem w programowaniu SharePoint są modyfikacje Web.config. Przypominam, że Web.config to nie smietnik, dodane wpisy należy usuwać gdy są już niepotrzebne. Należy też nauczyć się obsługi klasy SPWebConfigModification lub chociaż XPath'a, żeby nie dodawać np. duplikatów. Polecam feature'a do modyfikowania Web.config'a opisanego w tym poscieZasada nr 10.

Web.config trzymamy w należytym stanie. Dodajemy elementy i usuwamy kiedy są już nie potrzebne, zawsze używając SharePoint API. 

Rozszerzając funkcjonalność SharePoint'a często korzystamy z obiektów SPWeb, SPSite. Obiekty te   konsumują znaczne ilości pamięci operacyjnej. Na farmie SharePoint'a pamięć należy szanować, dlatego wszystkich programistów SharePoint'a zachęcam do uważnego wczytania się w artykuł 'Introduction to Using Disposable SharePoint Objects'. Po prostu 'Don't do evil' i nie produkuj memory leak'ów. Zresztą, nasz rodzimy SharePoint MVP Gutek o tym pisał np tutaj. Zasada nr. 11.

Programując w SharePoint szanuj nie tylko zieleń, ale i pamięć.


Na rynku dostępnych jest dużo produktów  partnerów Microsoft'u oferujących rozszerzenie funkcjonalności SharePoint'a. Może się zdarzyć, że wasz klient przymusi was do korzystania z takiego rozwiązania Out-of-the-box. Może ponieść to za sobą pewne konsekwencje, szczególnie przy instalowaniu nowych wersji, lub przy migracji na nową wersję SharePoint'a. Vendor oprogramowania może w dowolnej wersji naruszyć wstęczną kompatybilność (np. poprzez usunięcie feature'a), trzeba na to bardzo uważać i patrzeć mu na ręce analizując dostarczone pliki solution (WSP'y). Jest to o tyle istone, że rozwiązywanie potencjalnych problemów może spaść na biednego developer'a.  Zatem zasada nr. 12.

Jeżeli używasz komponentów 3rd-party to zaprzyjaźnij się z zespołem wsparcia tego produktu.  


Mam nadzieję, że ta lista "zasad" okaże się przydatna w uniknięciu chociaż części problemów z utrzymywaniem środowiska produkcyjnego opartego na platformie SharePoint.

Hope this helps.

Brak komentarzy:

Prześlij komentarz

Uwaga: tylko uczestnik tego bloga może przesyłać komentarze.