Programowanie w systemie Dynamics 365 – wzorce projektowe

Pisanie kodu uruchamianego na platformie Dynamics 365 CE na pozór wydaje się banalnym tematem. Tu biblioteczka JavaScript… Tam prosta DLL-ka .NET, uruchamiana w momencie wystąpienia określonego zdarzenia w systemie… Być może jest to prawda, jeżeli korzystamy z systemu w wersji „pudełkowej” lub dostosowanej za pomocą narzędzi dostarczonych przez producenta. Sprawy komplikują się jednak w przypadkach dużych wdrożeń, w których rozszerzenia (pluginy, biblioteki JavaScript, niestandardowe procesy i ich komponenty) liczone są w setkach lub nawet tysiącach. Bardzo łatwo wówczas dorobić się ogromnej bazy kodu spaghetti, nad którym z dnia na dzień jest coraz ciężej zapanować.

Wynikiem tej sytuacji jest coraz większa ilość błędów, które pojawiają się w systemie, rosnąca ilość wzajemnych zależności w kodzie, dłuższy czas i koszt dostarczania nowych funkcjonalności, oraz związane z tym wszystkich ogólne niezadowolenie końcowych użytkowników.

Niestety, jeżeli na początku projektu nie pomyślimy, w jaki sposób zorganizować nasz kod, na późniejszych etapach projektu staje się to już dużo trudniejsze. W czasie swojej kariery byłem świadkiem wielu wdrożeń systemów CRM/365CE, w przypadku których jedynym podejściem do pisania kodu była metoda „siadamy i ciśniemy” (żeby nie było, zdarzało mi się również popełniać podobne potworki w początkowych latach pracy). Sytuacja ta wynika w moim przekonaniu z faktu, że pozorna łatwość tworzenia kodu uruchamianego na platformie Dynamics 365 powoduje, że angażowani są do tego programiści z niewielkim doświadczeniem zawodowym, dla których podstawową kwestią w czasie tworzenia rozszerzeń funkcjonalnych jest to, że mają one działać. O czytelności kodu oraz możliwościach rozbudowy tworzonego rozwiązania nikt w takich sytuacjach nie myśli. Dodatkowo mam wrażenie, że w świecie doświadczonych programistów tworzenie rozszerzeń dla „zamkniętych” platform (Dynamics, SalesForce, SharePoint itp.) uchodzi za mało ambitne, mocno upierdliwe i niegodne ręki mistrzów zajęcie :). Natomiast w sytuacji, w której mamy już w zespole osobę, z odpowiednim bagażem doświadczeń, to bardzo szybko „awansowana” jest ona na konsultanta funkcjonalnego, lidera zespołu, czy też innego kierownika.  

W związku z powyższą sytuacją postanowiłem rozpocząć na blogu cykl wpisów, poświęconych wzorcom programistycznym oraz dobrym praktykom, które mogą być stosowane przez programistów systemu Dynamics 365 CE. Artykuły będą się pewnie pojawiać (jak to w moim przypadku bywa) mocno nieregularnie. Postaram się jednak w tym przypadku o większą częstotliwość niż 1 wpis na kilka miesięcy :P. 

Wstępny plan, będący jednocześnie spisem treści dla wspomnianego cyklu, znajdziecie poniżej. Oczywiście zastrzegam sobie prawo, do jego zmian i wszelkich modyfikacji ;).

  1. Klasa PluginBase
  2. Dostęp do danych – repozytorium oraz fabryka
  3. Wstrzykiwanie zależności.
  4. Wzorzec CrmCommand i Command Factory
  5. Testy jednostkowe – rozszerzenia .NET
  6. Pluginy – podejście do tworzenia, dobre i złe praktyki
  7. Fasada
  8. Dekorator
  9. Łańcuch odpowiedzialności
  10. Przetwarzanie asynchroniczne
  11. Moduły oraz przestrzenie nazw (JavaScript)
  12. MVVM (JavaScript)
  13. Projektowanie warstwy dostępu do danych (JavaScript)
  14. Testy jednostkowe – rozszerzenia JavaScript
  15. Harmonogramowe zadania
  16. Wzorce integracyjne

Total Views: 686 ,
This Article Has 4 Comments
  1. G Reply

    Wygląda ekstra Piotrek! Na pewno będę śledził 🙂

  2. Pingback: dotnetomaniak.pl

  3. Cezary B Reply

    Kiedy planujesz pierwszy wpis?
    Może zamiast JavaScript lepiej się skupić na TypeScript?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *