Efektem tworzenia frameworka (oprócz kodu źródłowego) powinny być oczywiście paczki NuGeta zawierające biblioteki dll. Samo ich stworzenie nie jest problemem, wszakże wystarczy kompilacja i nuget.exe wywołany z wiersza poleceń. Oczywiście można to robić ręcznie, ale ponieważ jestem leniwym programistą, wolę, aby działo się to automatycznie.

To właściwie powinien być pierwszy post dotyczący mojego projektu, ale najpierw musiałem zrobić małą refaktoryzację, a później znaleźć wenę. W tym poście opisuję podstawowe klasy, z których korzysta się w PizzaMVC, a także postaram się wyjaśnić czemu w taki sposób to zaimplementowałem oraz jakoś umotywować swoje decyzje projektowe. Zapraszam do lektury i ostrzegam, że będzie raczej długo.

Soft delete jest jednym z podstawowych pojęć, które spotyka się w świecie crudowych aplikacji. Właściwie trudno wyobrazić sobie, aby jakakolwiek rzeczywista biznesowa aplikacja mogła istnieć bez możliwości oznaczania rekordów jako usunięte zamiast ich fizycznego kasowania z bazy. (Niektórzy twierdzą nawet, że niczego nie powinno się z bazy usuwać - tak, na wszelki wypadek.) Oczywiście tak podstawowej funkcji nie mogło zabraknąć w moim frameworku. W tym poście opisuję w jaki sposób zaimplementowałem mechanizm soft delete w Pizzy, co przy okazji pozwala na pokazanie elastyczności i rozszerzalności NHibernate, czyli tych cech tego ORMa, których nie uświadczymy w konkrencyjnych produktach koncernu na M.

Jeśli ktoś jeszcze tego nie wie, to Razor Generator jest pomocnym narzędziem, które pozwala na umieszczanie widoków MVC w bibliotekach dll. W przypadku frameworka takiego jak PizzaMVC, jest to niezbędne - wszak z założenia wszystkie podstawowe widoki CRUDowe mają być częścią biblioteki. Brzmi prosto, ale w zeszłym tygodniu trochę czasu spędziłem zmagając się z prostym problemem, który wynikał z tego, że rzeczywistość jest trudniejsza niż tutoriale. ;)

Nie, to nie jest recenzja trzeciego dodatku do Munchkina. To wyjaśnienie, czemu ten blog jest smutny, jak i całe programistyczne życie. Ponadto, ten post w pewnym stopniu wyjaśnia, czemu PizzaMVC od strony technologicznej i architektonicznej, wygląda jak wygląda - bo po prostu jest zupełnym przeciwieństwiem patologicznego podejścia, które opisałem poniżej.

Celem mojego małego projektu jest utworzenie frameworka do webowych aplikacji typu CRUD. Można się zastanawiać, jaki sens ma tworzenie czegoś takiego, czy to tylko “sztuka dla sztuki”, czy wniesie on jakąś wartość dodaną dla twórcy aplikacji, czy faktycznie trzeba coś tworzyć, bo czyż sam ASP.NET MVC nie wystarcza do tworzenia aplikacji każdego rodzaju?

Aby rozwiać te wszystkie wątpliwości, w tym poście opisuję swoją motywację do stworzenia PizzaMVC, główne założenia tego frameworka, oraz to czym ma być, ale też czym ma nie być.

Każdy ma jakiegoś pierwszego posta na blogu, więc nie będę gorszy. ;)

Bloga planuję już od paru lat, ale dopiero wiadomy konkurs zmotywował mnie do wdrożenia tego planu w życie. Mam kilkadziesiąt pomysłów na posty, a i konkurs wymusza dodatkową tematykę, więc mam nadzieję, że nie będzie to kolejny blog z trzema wpisami na krzyż, jakich wiele w internecie.

Na początek smutny mem wyjaśniający tytuł bloga:

Smutne jest to, że w tak wielu miejscach “commit and run” to powszechna praktyka radzenia sobie z ułomnościami procesów, słabym kodem i niestabilnym CI. Że praca jest tak nudna, że ludzie ze zmęczenia z niechęcenia, po kolejnum dniu walki z syfem, robią takie rzeczy. Smutne jest to, że w tak wielu przedsięwzięciach wciąż korzysta się z systemów kontroli wersji zniechęcających do commitowania. Smutne jest to, że wszyscy widzą, że to jest złe, ale nikt z tym nic nie robi, bo wymagałoby to trzech rzeczy, których ludzie nie cierpią: samorozwoju, zmiany przyzwyczajeń i rozumienia narzędzi oraz procesów.