Proces wytwarzania oprogramowania jest przedsięwzięciem ograniczonym w czasie oraz o ograniczonym budżecie. Jego przebieg zależy od przyjętej metodyki lecz w przypadku dużych projektów jego etapy mają charakter formalny i często są wykonywane przez różne zespoły (np. Podstawowy przebieg: analiza,projekt,implementacja,testy).To sprawia ,iż wszelkie zmiany w założeniach kosztują więcej im prace są bardziej zaawansowane. W przypadku oprogramowania „pod klucz” można takie sytuacje ograniczyć do minimum np. Poprzez odpowiednio przeprowadzoną analizę, prototypowanie etc. Inaczej się sprawy mają przy produktach „pudełkowych”, gdzie wszelka kustomizacja następuje na etapie wdrożenia. Niemożliwe jest stworzenie rozwiązania w pełni uniwersalnego, które spełni wymagania każdego klienta. Dlatego konsultanci potrzebują czegoś więcej niż rozbudowanych opcji konfiguracyjnych, narzędzia które pozwalałoby na etapie wdrożenia zaimplementować specyficzne wymagania klienta bez cofania produktu do działu produkcji i wytwarzania osobnej wersji dla konkretnego klienta co znacznie zwiększyłoby koszty (czasami jest to nieuniknione). Jako projektant oprogramowania musiałem rozwiązać ten problem w aplikacjach napisanych w Silverlight. Z pomocą przyszedł mi DLR (Dynamic Language Runtime) który pozwala używać języków skryptowych w środowisku .NET. Jest to „nakładka” na CLR działająca poprzez refleksję. Obsługuje ona takie języki jak Python czy Ruby. Na prostym przykładzie postaram się pokazać korzyści jakie możemy odnieść udostępniając osobie wdrażającej system możliwość pisania skryptów. Python i Ruby dla platformy .NET mają swoje odpowiedniki IronPython i IronRuby, które są projektami prowadzonymi na codeplex.com. Istnieją dwa sposoby integracji DLR z aplikacją Silverlight. Pierwszy to odwołanie się do obiektów SL w kodzie HTML (poprzez JavaScript) strony hostującej xapa. Druga metoda polega na wykorzystaniu odpowiedniego API w kodzie zarządzalnym aplikacji SL. W moim przykładzie skorzystam z drugiej opcji. Załóżmy ,że implementujemy program do wysyłania faktur. Nasz dział produkcji stworzył bardzo dobrze działającą aplikację, której funkcjonalność zadawala większość klientów. Niestety jeden z potencjalnych nabywców oznajmił nam , że kupi aplikację jeśli data wystawienia będzie automatycznie ustawiania na dzisiejszą a kwota w momencie wysłania będzie przeliczała się według podanego kursu (ps. Przedstawiane wymagania są trywialne mało życiowe , mają na celu tylko pokazanie potencjalnego zastosowania DLR). W przypadku braku narzędzia dla konsultanta/wdrożeniowca musiałaby powstać osobna wersja w dziale produkcji, która musiałaby przejść testy etc. Można tego uniknąć implementując tą funkcjonalność w DLR na etapie w wdrożenia. W przykładzie wykorzystam język IronPython. By rozpocząć pracę należy pobrać odpowiednie biblioteki (Microsoft.Scripting i IronPython) ze :
strony projektu . Nasza aplikacja wygląda następująco :
By korzystać z DLR musimy dodać odpowiednie referencje:
Następnie w konstruktorze głównej klasy tworzę obiekty typu ScriptEngine i ScriptScope oraz poprzez SetVariable ustawiam zmienną w DLR odnoszącą się do obiektu TextBoxa. Ostatnią czynnością jest utworzenie skryptu i jego wykonanie. W metodzie podpiętej pod przycisk wyślij ustawiam kolejną zmienną (textbox z kwotą). Oraz wywołuje uruchamiam skrypt mnożący wpisaną kwotę przez wartość kursu.
Po uruchomieniu wpisaniu kwoty 2 i naciśnięciu przycisku dostajemy następujący rezultat:
Jaki widać przy pomocy skryptu DLR udało nam się ustawić wartość domyślną oraz zrealizować prostą logikę przetwarzania danych. Oczywiście projektując system należy przemyśleć w których miejscach tego typu „hooki” będą dostępne dla wdrożeniowca oraz stworzyć warstwę pośrednią udostępniającą odpowiednie obiekty kodu zarządzalnego.
Brak komentarzy:
Prześlij komentarz