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
  3. Fabryka obiektów
  4. Wstrzykiwanie zależności.
  5. Wzorzec CrmCommand i Command Factory
  6. Testy jednostkowe – rozszerzenia .NET
  7. Pluginy – podejście do tworzenia, dobre i złe praktyki
  8. Fasada
  9. Dekorator
  10. Łańcuch odpowiedzialności
  11. Przetwarzanie asynchroniczne
  12. Moduły oraz przestrzenie nazw (JavaScript)
  13. MVVM (JavaScript)
  14. Projektowanie warstwy dostępu do danych (JavaScript)
  15. Testy jednostkowe – rozszerzenia JavaScript
  16. Harmonogramowe zadania
  17. Wzorce integracyjne

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

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

  2. Pingback: dotnetomaniak.pl

  3. Cezary B

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

Comments are now closed.