Wymyślanie koła za każdym razem, kiedy chciałoby się pojechać na zakupy byłoby szalenie niepraktyczne. Dlatego programiści często tworzą niestandardowe narzędzia, aby usprawnić swoją pracę, poprzez automatyzację, stworzenie bibliotek pomocniczych, czy napisanie pełnoprawnych aplikacji, które pomagają w wykonywaniu zadań.
W związku z tym nie było dla mnie zaskoczeniem, kiedy podczas pracy z różnymi firmami tworzącymi aplikacje dla biznesu, znajdowałem szeroką gammę wewnętrznych zestawów SDK. Niestety, chociaż były one pomocne, nigdy nie były stosowane we wszystkich projektach, a w wielu przypadkach były stosowane niespójnie, nawet w obrębie jednego projektu.
Dlatego w ARP Ideas postanowiliśmy stworzyć rozwiązanie, które odpowiadałoby na ten problem. Początki były podobne do tego, jak wygląda to w innych firmach – kilka klas pomocniczych i narzędzi ręczni kopiowanych z projektu do projektu. Jednak wkrótce narodziła się myśl, która stała się fundamentem naszej filozofii:
„Co gdybyśmy mogli korzystać z naszych wewnętrznych zestawów SDK w dosłownie wszystkich projektach? Niezależnie od tego, czy pracujemy nad projektem Microsoft Dynamics 365, Microsoft SharePoint, czy w ramach niestandardowej witryny ASP?”.
Warstwa luźnych powiązań (ang. Loose coupling)
Nasze narzędzia to nie tylko zestaw klas pomocniczych, które po wywołaniu „robią przydatne rzeczy” lecz stanowią całkowicie nową warstwę, na której pracujemy. Ta warstwa wiąże ze sobą klasy modeli, repozytoria danych i logikę biznesową z podstawową warstwą danych i w stosownych przypadkach łączy się z istniejącym systemem, np. jako wtyczki Microsoft Dynamics 365.
Odbywa się to za pomocą paradygmatu „luźnych powiązań” (ang. „loose coupling”) z kilkoma sprytnymi klasami podstawowymi dorzuconymi do repo. Każda klasa logiczna implementuje własny interfejs, korzysta z interfejsów repozytorium w celu uzyskania dostępu do danych, a repozytoria zwracają nasze modele danych. Po utworzeniu podstawowych struktur projektu programista nie musi zwracać uwagi na to, czy tworzy logikę dla Microsoft Dynamics 365, Microsoft SharePoint lub czegoś innego.
Same repozytoria opierają się na zestawie potężnych klas bazowych dla najpopularniejszych źródeł danych, z którymi współpracujemy: encji CRM, list SharePoint czy niestandardowych zestawów danych SQL (dostępnych za pośrednictwem Entity Framework).
Testowanie ze wszystkich stron
Dzięki luźnym powiązaniom między klasami łatwo przetestować naszą logikę – nawet bez uruchamiania interfejsu użytkownika. Klasyczne testy jednostkowe są świetne, jeśli logika pozwala na ich użycie. Niestety często istnieje przynajmniej jeden element istniejącego systemu, który odgrywa kluczową rolę w logice. Testowanie metody, która oblicza średnią na podstawie kilku podanych wartości jest proste… testowanie metody, która oblicza średnie systemowe po dodaniu nowego rekordu? Niekoniecznie.
Aby ułatwić testowanie, możemy wykorzystać kilka sprytnych klas pomocniczych z naszej biblioteki Projects, takich jak repozytoria danych „tylko do odczytu”, które umożliwiają testowanie z wykorzystaniem rzeczywistych danych (na przykład z CRM) i zapisywanie zmian tylko w pamięci. To pozwala nam przetestować naszą logikę zależną od systemu bez uruchamiania systemu bazowego lub bez wprowadzania zmian.
Rozwój oparty na danych biznesowych
Zwykle programowanie oparte na zdarzeniach oznacza implementowanie i używanie zdarzeń w kodzie. Jednak w tym wypadku chcemy skupić się na wydarzeniach związanych z przetwarzaniem danych biznesowych. Na przykład – w jaki sposób powinien zareagować system, jeżeli użytkownik doda do systemu nowy rekord.
Oparliśmy to w luźny sposób o reguły wykonywania zdarzeń z Microsoft Dynamics 365, gdzie każda operacja (w stosownych przypadkach) ma kilka etapów – walidacji, operacji wstępnej i postoperacji. Projekty dla CRM mapują te etapy prawie 1 do 1 dla podstawowych operacji CRUD w naszym kodzie, a nasze repozytoria pozwalają nam na wdrożenie takiego mechanizmu dla każdego projektu, na jakim pracujemy.
Sięgnij głębiej dzięki repozytoriom metadanych
Kolejnym etapem rozwoju było stworzenie repozytoriów metadanych i integracja ich z naszym podstawowym kodem Projects. Główny zamysł był taki, aby mieć domyślną funkcjonalność CRUD opartą na informacjach metadanych, zamiast polegać na repozytoriach utworzonych przez programistów.
Te oczywiście mogą i nadal będą istnieć, każdy bardziej zaawansowany kod logiczny prawdopodobnie będzie wymagał tych tradycyjnych repozytoriów. Ale dzięki implementacji metadanych możemy znacznie szybciej tworzyć podstawowe formularze i funkcje, ponieważ ten proces został zautomatyzowany.
Zautomatyzowane wdrażanie
Nasz pakiet SDK Projects wykorzystuje niestandardowe atrybuty, co pozwala nam oznaczać interfejsy logiczne dodatkowymi metadanymi. Można to wykorzystać do zautomatyzowania procedur wdrażania. Chociaż nadal jest to rozwijany projekt, dysponujemy już narzędziem, które w pełni automatyzuje wdrażanie wyczek do Microsoft Dynamics 365 utworzonych przy użyciu naszych pakietów SDK Projects.
Chociaż podstawową zasadą takich narzędzi jest przyspieszenie i uproszczenie wdrażania, ważna jest elastyczność w dostosowywaniu niestandardowych lub niestandardowych kroków wdrażania. W związku z tym narzędzie do wdrażania Microsoft Dynamics 365 obsługuje konfigurację innych, mniej standardowych kroków i etapów zdefiniowanych przez użytkownika.
Skontaktuj się z nami za pomocą formularza TUTAJ, zadzwoń pod numer +48 61 624 86 40 lub napisz na adres