Obiektowy sposób pracy z modelami i aplikacjami internetowymi
Kiedy mówimy o koncepcji modeli w programowaniu obiektowym, zwykle mamy na myśli klasę, która jest reprezentacją danych przechowywanych w bazie danych.
Oznacza to, że gdy informacje są przechowywane w wierszach i kolumnach, wypełniamy klasę, jej atrybuty i tak dalej tymi informacjami, aby móc przekazywać je do aplikacji, manipulować nimi w razie potrzeby, a następnie ewentualnie serializować dane z powrotem do bazy danych.
Ale w aplikacji internetowej można uczciwie założyć, że model musi być możliwy do użycia w interfejsie użytkownika. Oznacza to, że wyobraźmy sobie żądanie frontonu wywołujące serwer, żądające modelu (lub kolekcji modeli), a następnie renderujące je na stronie frontowej.
Chociaż ten konkretny post nie jest zorientowany na kod, nadal uważam, że warto przemyśleć proces tłumaczenia modelu z serwera, a następnie renderowania go na interfejsie aplikacji internetowej.
Praca z modelami i aplikacjami internetowymi
Wyobraź sobie przez chwilę, że Twoja aplikacja ma model Pracownika. Ten model może zawierać różne atrybuty, ale można bezpiecznie założyć, że wszyscy pracownicy mieliby:
- imię,
- nazwisko,
- identyfikator pracownika,
- i adres e-mail
Sposób przechowywania tych informacji w bazie danych nie jest całkowicie bez znaczenia, ale nie jest tak ważny dla tej dyskusji.
Na przykład być może istnieje pojedynczy rekord, który zawiera wszystkie te informacje przechowywane w ciągu JSON. Z drugiej strony, być może istnieje tabela pracowników, w której każdy wiersz reprezentuje pracownika, a każda kolumna reprezentuje atrybut.
Szczegóły, w jaki sposób informacje są tłumaczone z bazy danych (lub, bardziej ogólnie, magazynu danych) na klasę, nie są tak ważne.
Zwykle jednak zobaczymy coś takiego:
- Istnieje klasa, która żąda informacji,
- Informacje przekazywane są do Prostej Fabryki ,
- Prosta fabryka tworzy instancję Modelu ,
- Model jest następnie przekazywany do klasy innej firmy, która go zażądała.
Z poglądowego punktu widzenia możesz to zobaczyć w ten sposób:
Od tego momentu Model jest przekazywany przez aplikację. Ale tutaj pojawia się początkowy punkt tego postu: jak przekazać instancję Modelu (lub kolekcję Modeli) do frontonu aplikacji?
Przepływ aplikacji internetowej
Aby uprościć sprawę, załóżmy, że będziemy używać jednego modelu, a następnie, jeśli ponownie przyjrzę się tej koncepcji z punktu widzenia kodu, możemy zagłębić się nieco dalej.
Ogólny przepływ aplikacji internetowej będzie jednak wyglądał mniej więcej tak:
- Użytkownik uruchamia akcję, która żąda wystąpienia modelu,
- Front-end wykonuje wywołanie do punktu końcowego na serwerze,
- Serwer odczytuje żądania i weryfikuje ich poprawność,
- Następnie wysyła reprezentację modelu do front-endu.
Inni programiści mogą się z tym nie zgodzić (co moim zdaniem zawsze jest mile widziane i warte dyskusji), ale odkryłem, że serializacja instancji modelu do JSON znacznie ułatwia pracę na interfejsie ze względu na funkcjonalność JavaScript, ponieważ odnosi się do, ahem, JSON.
Innymi słowy:
- bierzemy model,
- zserializować go do JSON,
- wyślij to przez drut,
- następnie zdeserializować go w interfejsie do reprezentacji samego siebie w JavaScript.
To pozwala nam manipulować nim tak, jak po stronie serwera; jednak mamy do czynienia z obiektem JavaScript. Co więcej, pozwala nam również na dokonywanie pewnych zmian i wysyłanie informacji z powrotem na serwer w innym stanie, z którego zostały wysłane.
Ostatecznie pozwala nam to zapisać dane z powrotem do bazy danych.
Perspektywa wysokiego szczebla
I to jest cykl życia wysokiego poziomu, polegający na przekazywaniu informacji z bazy danych do modelu do interfejsu i z powrotem.
Często jednak pomaga zobaczyć to w kodzie, więc być może w przyszłym poście przedstawię serię artykułów, w których wyjaśnię, jak to zrobić.
W międzyczasie jednak przetłumaczenie implementacji na przepływ pracy Model-Serialization-Request-Send nie powinno być trudne, jak opisano w tym poście.