Czy jeśli tworzę sklep internetowy to czy do dodawania, edycji, wyświetlania produktu należy tworzyć oddzielny viewModel?
0
1
A czy jeden viewmodel będzie zgodny z SRP?
0
@somekind: ale oczywiście. Jego zadaniem jest bycie viewmodelem.
Tak jak czasem klasy piramidowe, najlepiej jak na środku jest stożek i to jest tej klasy zadanie :D
1
dodawanie, edycja , wyświetlanie to przecież typowowy CRUD. Jak dla mnie wystarczy jeden view model bo to ciągle są te same dane.
0
@Akihito: to czy takie operacje to crud to zależy od modelu aplikacji a nie od nazw operacji.
Czasami dodajesz coś innego niż wyswietlasz. Np
niedawno tak miałem w app do laboratorium. Dodawane byly surowe pomiary chemiczne a wyświetlane wyniki przeliczen tych pomiarów na jakieś ludzkie wskaźniki.
0
Zakładam, że mając sklep internetowy produkty trzymasz w bazie danych. Wykonując operację dodania/edycji potrzebujesz pełnego modelu by wstawić/edytować produkt na bazie danych. Wyświetlanie tez bazuje na tych samych informacji z tabeli bazy danych. Tak więc jest to typowy CRUD w tym przypadku. @jacek.placek masz rację, w twoim przypadku są to dwie różne rzeczy. Aczkolwiek podejrzewam, że autorowi chodziło o prosty sklep z produktami.
1
No nie wiem. Sklepu nigdy nie pisałem ale pisałem coś a'la B2B. Tam dodanie produktu to było ze 25 parametrów. Edycja zakładała, ze niektóre z nich nie mogą się zmieniać (był jakiś tryb administracyjny ale z własnym viewmodelem).
Podgląd produktu miał właściwie tylko nazwę i kod (do filtrowania). A często produkt w sklepach ma np informacje o dostępności (ilość w magazynie), która to nijak się ma do R z CRUD-a.
Dodawanie produktu do zamówienia to jeszcze co innego bo trzeba było wybrać opcje, sprawdzić poprawność opcji (niektóre się wykluczały) itp.
Nie było żadnych szans, żeby ot zrobić na jednym viewmodelu. A potem oczywiście mnóstwo zmian w odpowiednich viewmodelach i takie rozdzielenie viewmodeli dla różnych akcji było bardzo pomocne.
Jak ktoś pracuje kilka lat to wie, że "prosty sklep z produktami" po jakimś czasie zrobi się nieco mniej prosty :)
0
jacek.placek napisał(a):
Nie było żadnych szans, żeby ot zrobić na jednym viewmodelu. A potem oczywiście mnóstwo zmian w odpowiednich viewmodelach i takie rozdzielenie viewmodeli dla różnych akcji było bardzo pomocne.
E tam, trzeba po prostu dowalić odpowiednią liczbę właściwości w stylu IsNameVisibleOnEditScreen, IsNameVisibleOnDetailsScreen itd. dla każdej wartości i trochę ifów w widokach.
Do tego jeszcze dodać mapowania ORMa i metadane rekordu (tylko trzeba im dodać IsVisibleOnXScreen na false), i viewmodele możemy od razu zapisywać do bazy!
Na tym przecież polega Single Responsibility Principle - Single, czyli JEDNA klasa w całym systemie. A nie jakieś tam lamerskie rozdrabnianie się.
0
Na tym przecież polega Single Responsibility Principle - Single, czyli JEDNA klasa w całym systemie. A nie jakieś tam lamerskie rozdrabnianie się.
A tak masz racje zapomniałem.... Przecież tylko debile i lamusy tworzą Generyczne ViewModele adekwatnie do zachowania modelu (w tym wypadku requestów). No przecież SRP rządzi się tabelkami w DB zamiast zachowaniami.
A generyczne widoki przież to już samo zło no bo jak to jedna klasa na tyle tabelek a gdzie SRP.?
0
Enter Name napisał(a):
A tak masz racje zapomniałem.... Przecież tylko debile i lamusy tworzą Generyczne ViewModele adekwatnie do zachowania modelu (w tym wypadku requestów). No przecież SRP rządzi się tabelkami w DB zamiast zachowaniami.
No przecież jeśli mówimy o rozdzielaniu viewmodeli per czynność, to chodzi właśnie o separację zachowań. Baza danych nie ma nic do rzeczy, może jej nawet nie być.
A generyczne widoki przież to już samo zło no bo jak to jedna klasa na tyle tabelek a gdzie SRP.?
Generyczne widoki to samo dobro.