Z reguły naszą logikę biznesową umieszczamy w klasach serwisowych. Czasem są one większe, a czasem mniejsze. Zastanówmy się, jak mógłby wyglądać nasz kod, gdybyśmy dla każdej metody z serwisu tworzyli osobną klasę. Wykorzystamy do tego bibliotekę MediatR. Jeśli ktoś się zastanawia po co, odpowiedź jest prosta: aby zwiększyć spójność i zmniejszyć sprzężenie. Na razie nie będziemy się zagłębiać w takie pojęcia jak CQRS czy CQS. Naszym celem jest rozbicie klas na mniejsze i zmiana tego, jak je wołamy. Po ty...

Z reguły nasze aplikacje posiadają jakąś logikę biznesową (o ile nie piszemy prostego CRUD). Chciałbym jednak zaznaczyć, że nie mam tu na myśli logiki w rozumieniu walidacji czy reguł biznesowych, np. brak możliwości zmiany wartości jakiegoś pola, gdy pewne warunki nie zostaną spełnione. Chodzi mi bardziej o logikę procesu, np. gdy klient złoży zamówienie, musimy mu wysłać wiadomość e-mail. Ta logika nie dotyczy obiektu zamówienia, ale jest z nim związana. Skoro wiemy, że będziemy musieli przechowywać g...

Jakiś czasem temu pisałem o tym, że nasze metody mogą zwracać rezultat lub zgłaszać wyjątek (tutaj). Zastanówmy się, jak mogłoby wyglądać nasze API, aby status rezultatu był mapowany na odpowiedni kod Http. Mamy dwie możliwości: wspólna metoda w klasie bazowej lub filtr.

Często na GitHubie w opisach projektów można zobaczyć Badge – odznaki pokazujące status builda, pokrycia kodu, status testów i innych rzeczy. Jak zrobić coś takiego i czy w ogóle warto?

Witajcie w sześćdziesiątym odcinku Ostrej Piły. W tym trochę technicznie – porozmawiamy o zarządzaniu zależnościami. Z naszym gościem, porozmawiamy o jakie zależności możemy mieć w projekcie i czy zawsze trzeba nimi zarządzać a jeśli tak to jak możemy to zrobić. A na koniec o tym czy w świecie .NET grozi powtórka sytuacji z left-pad? Miłego słuchania. 🎶

Kiedyś bardzo lubiłem bibliotekę AutoMapper. Była ona z reguły jedną z pierwszych bibliotek, jakie zawsze dodawałem do projektu na samym początku. Pozwalała mi tworzyć mnóstwo obiektów i mapować je do woli, poświęcając na to niewiele czasu „programistycznego”. Była świetna! Aż do momentu, gdy zaczęła być jedną z największych bolączek.

Często gdy mamy napisać jakiś kod, okazuje się, że już gdzieś napisaliśmy taki sam lub podobny. Wtedy stajemy przed dylematem – czy zduplikować go, czy użyć ponownie?

Jakiś czas temu pisałam na temat innych serwisów Azure DevOps – Repos i Pipelines. Dzisiaj czas na Boards i konkretny problem ustawienia procesu dla naszego projektu.

Pisząc aplikację zwykle piszemy testy. Raczej nie muszę wyjaśniać po co 🙂 Czy tworząc różne procedury lub funkcje na bazie danych też sprawdzamy ich poprawność pisząc testy? Tu już niekoniecznie. A szkoda, bo pisanie testów w tSQLt nie różni się za bardzo od pisania zwykłych testów jednostkowych...

General Responsibility Assignment Software Patterns (GRASP) to zbiór 9 zasad określających, jaką odpowiedzialność powinno się przypisywać określonym obiektom i klasom w systemie. Wszystkie te zasady odpowiadają na część problemów z oprogramowaniem, które są wspólne dla prawie każdego projektu. Techniki te nie zostały wymyślone w celu stworzenia nowych sposobów pracy, a jedynie w celu lepszego udokumentowania oraz standaryzacji starych, wypróbowanych i przetestowanych zasad programowania. Jest więc to kol...