Trochę historii, czyli skąd pomysł na własny framework?

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ć.

Trochę historii.

Mój framework (wtedy jeszcze bez nazwy) zaczął powstawać w 2013 roku jako część pewnej aplikacji, którą tworzyłem jako freelancer. Z tego przedsięwzięcia ostatecznie nic nie wyszło, ale zostało sporo kodu, który dało się użyć jako baza do tworzenia kolejnych aplikacji. Tym sposobem gdzieś tak pod koniec 2013 roku miałem już gotowe 90% frameworka. Dziś, po ponad dwóch latach pracy po godzinach, czasami po godzinie wieczorem, czasami po kilka godzin w weekend, czasami kilka miesięcy bez commita, po dodaniu testów, przykładowej aplikacji, naprawie dziesiątek śmiesznych błędów, przejściu na MVC 5 i Bootstrapa, sporych rotacjach w klasach, podziale jednej dużej biblioteki dll na cztery, mam już gotowe 90% frameworka. Pozostałe 90% mam zamiar napisać w ciągu tych konkursowych 10 tygodni.

Co powinien posiadać framework crudowy?

Spróbuje tutaj zdefiniować wymagania funkcjonalne, bez wnikania w szczegóły implementacyjne. Pewno, gdybym od tego zaczął prace, to 90% frameworka osiągnąłbym znacznie wcześniej.

• Wyświetlanie gridów, pozwalających na ich filtrowanie, sortowanie, stronicowanie oraz linków do edycji, podglądu sczegółów oraz usuwania danych rekordów.
• Formularze tworzenia i edycji nowych rekordów z uwzględnieniem typów danych pól. (Tekst, data, wartość logiczna, edytor HTML, itp.)
• Efektywne wczytywanie jedynie potrzebnych danych z bazy, zarówno bez problemu select n+1, jak i wybieranie jedynie kolumn, które mają trafić do grida.
• Łatwa w użyciu oraz automatyczna transakcyjność operacji bazodanowych.
• Audyt operacji tworzenia/edycji rekordów przy użyciu danych
• Łatwy w zastosowaniu soft delete.
• Automatyczne optimistic concurrency w przypadku edycji rekordów.
• Sposób przechowywania danych w bazie (typy, zakres, długość napisów) definiowane atrybutami.
• Klasy definiujące wiersze bazy danych oraz klasy definiujące dane wyświetlane
• Brak udawanego DDD, brak zbędnych warstw, brak bezużytecznych wrapperów w rodzaju “generycznych repozytoriów”.
• Kontrolery nie zawierające logiki biznesowej ani aplikacyjnej, nie wiedzące nic o bazie danych ani nie korzystające bezpośrednio z ORMa, ani żadnego DAO (bez względu na jego nazwę).
• Kontrolery korzystające z serwisów aplikacyjnych, komunikujące się z nimi na zasadzie żądanie-odpowiedź wyłącznie przy pomocy viewmodeli (czyli de facto prostych DTO).
• Serwisy aplikacyjne enkapsulujące operacje crudowe, ale pozwalające też na rozszerzenie tej logiki. A nawet na enkapsulowanie prawdziwego DDD - oczywiście bez wiedzy kontrolerów.
• Wypełnienie bazy mockowymi danymi, zgodnymi z regułami walidacji.

Obecnie PizzaMVC zapewnia to wszystko i jeszcze wiele innych rzeczy. Ale jest też wiele do zrobienia. Listę brakujących funkcji i rzeczy do refaktoryzacji postaram się zamieścić niebawem.