W modelu mam rozmiar pliku w bajtach jako int. W zależności od rozmiaru pliku chciałbym zaprezentować go jako x GB lub x MB lub x KB.
Czy to model powinien dostarczyć pole z już przekształconą wielkością? Czy możliwe jest w widoku dodatnie takiej logiki? Czyli aby zamiast int 1200000 mieć string 1,2MB?
Używam MVC 4 z Razor.
1
0
Ja bym zrobił w modelu właściwość np. DisplaySize, która zwracałaby rozmiar do wyświetlenia w widoku.
Do widoku nie pchałbym takiej logiki, bo widok powinien być głupi.
0
No właśnie to jest jedna argumentacja którą mogę się kierować.
Z drugiej strony co Model obchodzi jak poszczególne dane będą prezentowane. Widok1 będzie prezentował je tak, a Widok2 siak. Czyli to widok powinien wiedzieć jak ma sobie sformatować dane, aby wyświetlić je zgodnie z założeniem. Bo zaraz okaże się że na potrzeby widoku2 trzeba dodać pole DispalySize2, albo nowy model.
Kiedy mamy do czynienia z typami ktore formatuje się łatwo i zwyczajowo przez ToString (jak daty, liczby) to nie ma problemu, łatwo zrobić to po stronie widoku i rozwiązanie jest nadal czytelne i raczej nie krytykowane.
Gorzej jak formatowanie to nieco bardziej skomplikowana transformacja.
A jeśli jednak chciałbym rozwiązać to po stronie widoku, to jakie rozwiązanie sugerujesz? Które nie wprowadzałoby zbyt dużo śmieci do widoku? Jakiś konwerter i widok1 wywoła sobie konwerter1, widok2 - konwerter2, a widok3 wyświetli czystą daną? Nie mogę złapać punktu zaczepienia o czym mam poszukać artykułów żeby to rozgryźć w rozsądny sposób.
0
Po kawie się lepiej myśli...
Napisałem custom formatter.
Na View wołam string.Format(new MojFormatter(), "{0}", model.FileSize).
Można też pomyśleć o rozszerzaniu HTML Helpera, ale to raczej w przypadku kiedy na wyjściu chcemy trochę bardziej skomplikowany html, a nie tylko jakś daną sformatowaną/przekształconą. Można także stworzy własne klasy pomocnicze z metodami statycznymi, które zostaną wywołane z modelu.
Czekam na wskazanie ewentualnych minusów takiego podejścia.
0
Można także stworzy własne klasy pomocnicze z metodami statycznymi, które zostaną wywołane z modelu.
Wydaje mi się, ze za dużo się zastanawiasz nad wzorcami czy obiektowością, a za mało nad po prostu rozwiązaniem problemu.
Ja bym zaczął od tego:
static string IntToSizeInBytes(int size)
{
...
}
a potem jakby co, łatwo przecież przerobić na cokolwiek.
0
Borycy napisał(a):
Z drugiej strony co Model obchodzi jak poszczególne dane będą prezentowane. Widok1 będzie prezentował je tak, a Widok2 siak. Czyli to widok powinien wiedzieć jak ma sobie sformatować dane, aby wyświetlić je zgodnie z założeniem. Bo zaraz okaże się że na potrzeby widoku2 trzeba dodać pole DispalySize2, albo nowy model.
Oczywiście. W widokach zazwyczaj nie ma sensu wyświetlać bezpośrednio encji, czy innych klas będących tzw. data modelami. Tworzy się ViewModele - inne dla widoku typu lista, inne dla szczegółów, inne dla dodawania i edycji. ViewModele "łączą" w pewien sposób dane z Modelu z tym, co i jak jest potrzebne w Widoku.
Nie wiem, czy pisanie custom formatterów, czy htmlhelperów w tym momencie nie wprowadzi zamieszania w projekcie, ale to już musisz sam ocenić.