🚀 go-pugleaf

On Thu, 27 Oct 2011 14:18:11 +0000, KO wrote:
> Mój problem:
> Mam model powiedzmy:
> Order: OrderNo, OrderType, Description......
> 
> Mam widok do tworzenia zamówienia - przywiązany do tego modelu.
> Użytkownik powinien wybrać OrderType z listy dostępnych typów, skąd mam
> wziąść te wartości widoku nie używając ViewRzeczy?
> Wsadzanie wszystkich istniejących OrderTypów do typu Order nie ma sensu
> IMO.
> Jest na to jakiś elegancki pattern czy jednak ViewCoś?

Ten pattern się nazywa View Model :).

View Model != Domain Model. Wiemy i rozumiemy, że bardzo wygodnie
posługiwać się Domain Modelem jako View Modelem, ale jest to
"bad practice", nie będę przywoływał źródeł, bo mi się nie chce :).

Czyli, w widokach operujesz na OrderViewModel, nie na Order.
Tenże VM jest specjalizowany do tego widoku, czyli oprócz
podstawowych pół bezpośrednio z Order(dziedziczonych na 
przykład), ciągnie ze sobą jeszcze meta dane w postaci
kolekcji wszystkich OrderType'ów i wszelkie inne pomocnicze
rzeczy jakich wymaga ten widok.

A do przepisywania wartości pomiedzy VM a Domeną, można naprzykład
użyć narzędzi podobnych do AutoMappera.

*pac* "wziąć" ;-).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

On Thu, 27 Oct 2011 16:58:21 +0200, Łukasz 'Maly' Ostrowski wrote:

> Czyli, w widokach operujesz na OrderViewModel, nie na Order.
> Tenże VM jest specjalizowany do tego widoku, czyli oprócz
> podstawowych pół bezpośrednio z Order(dziedziczonych na 
> przykład), ciągnie ze sobą jeszcze meta dane w postaci
> kolekcji wszystkich OrderType'ów i wszelkie inne pomocnicze
> rzeczy jakich wymaga ten widok.

W sumie ma sens, tylko się zastanawiam czy to nie jest over-engineering?
Jakie są zalety zastosowania MVVM(tak się to nazywa prawda?).
Muszę stworzyć dodaktową gałąź kodu, mam teraz View, Model, Controller,
ViewModel - robi się trochę ciasno :)

Zamiast tego mogę po prostu zrobić:

OrderController : Controller
{
  public View New()
  {
    ViewBag.OrderTypes = DataRefs.GetOrderTypes();
    ViewBag.Blah = MachineThatGoesPing.Ping();
    return this.View(new Order());	 
  }
}

Nie jest to może koszerne, ale jakie sa minusy takiego rozwiązania w
porównaniu do tworzenia dodatkowego ViewModel?

> *pac* "wziąć" ;-).

Auć.

dzięki, pzdr.

On Thu, 27 Oct 2011 15:54:50 +0000, KO wrote:
> W sumie ma sens, tylko się zastanawiam czy to nie jest over-engineering?
> Jakie są zalety zastosowania MVVM(tak się to nazywa prawda?).

Tak. Zaletą jest followowanie idei MVVM :). Pozatym, ja sam nie
widze jakichś przesadnych jasno wyrysowanych zalet ;-). 
Aczkolwiek, przykładowo, do widoku dzięki temu nie trafiają 
dane które powinny być tam niewidocznie, np. relacje na obiekcie
domenowym, które spowodują lazy-loading jak ktoś będzie próbował
dereferencnąć w/w ;-).

> Muszę stworzyć dodaktową gałąź kodu, mam teraz View, Model, Controller,
> ViewModel - robi się trochę ciasno :)

Jest ciężko :).

> Zamiast tego mogę po prostu zrobić:
> 
> OrderController : Controller
> {
>   public View New()
>   {
>     ViewBag.OrderTypes = DataRefs.GetOrderTypes();
>     ViewBag.Blah = MachineThatGoesPing.Ping();
>     return this.View(new Order());	 
>   }
> }
> 
> Nie jest to może koszerne, ale jakie sa minusy takiego rozwiązania w
> porównaniu do tworzenia dodatkowego ViewModel?

Możesz, generalnie rule-of-thumb - rób tak jak Tobie wygodnie
byle było spójne w całym projekcie :).
To jest znacząca oszczędność czasu.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/

Dnia 27-10-2011 o 17:54:50 KO <mail@example.com> napisał(a):

> On Thu, 27 Oct 2011 16:58:21 +0200, Łukasz 'Maly' Ostrowski wrote:
>
>> Czyli, w widokach operujesz na OrderViewModel, nie na Order.
>> Tenże VM jest specjalizowany do tego widoku, czyli oprócz
>> podstawowych pół bezpośrednio z Order(dziedziczonych na
>> przykład), ciągnie ze sobą jeszcze meta dane w postaci
>> kolekcji wszystkich OrderType'ów i wszelkie inne pomocnicze
>> rzeczy jakich wymaga ten widok.
>
> W sumie ma sens, tylko się zastanawiam czy to nie jest over-engineering?
> Jakie są zalety zastosowania MVVM(tak się to nazywa prawda?).
> Muszę stworzyć dodaktową gałąź kodu, mam teraz View, Model, Controller,
> ViewModel - robi się trochę ciasno :)
>
> Zamiast tego mogę po prostu zrobić:
>
> OrderController : Controller
> {
>   public View New()
>   {
>     ViewBag.OrderTypes = DataRefs.GetOrderTypes();
>     ViewBag.Blah = MachineThatGoesPing.Ping();
>     return this.View(new Order());	
>   }
> }
>
> Nie jest to może koszerne, ale jakie sa minusy takiego rozwiązania w
> porównaniu do tworzenia dodatkowego ViewModel?
>

Dodałbym, że w ViewModel możesz zawrzeć logikę (testowalną) zamiast wrzucać
ją do html-a (cshtml-a) i zamiast programować w cshtml-u programujesz  
wewnątrz ViewModelu.


-- 
3P

On Thu, 27 Oct 2011 19:10:13 +0200, Łukasz 'Maly' Ostrowski wrote:

>> Nie jest to może koszerne, ale jakie sa minusy takiego rozwiązania w
>> porównaniu do tworzenia dodatkowego ViewModel?
> 
> Możesz, generalnie rule-of-thumb - rób tak jak Tobie wygodnie
> byle było spójne w całym projekcie :).
> To jest znacząca oszczędność czasu.

Ha! Najwygodniej to mi jest w web forms, ale już od jakiegoś czasu czuję
się z tym jakoś niebardzo, mam wrażenie, że web forms jest już faux pas.
Więc chyba tak zostawię, troszkę brudku C->V ale mniej kodu.

pozdrawiam.

On Thu, 27 Oct 2011 18:30:03 +0000, KO wrote:
> Ha! Najwygodniej to mi jest w web forms, ale już od jakiegoś czasu czuję
> się z tym jakoś niebardzo, mam wrażenie, że web forms jest już faux pas.
> Więc chyba tak zostawię, troszkę brudku C->V ale mniej kodu.

Mnie zawsze WebForms odstraszało tym, że za dużo się dzieje
"behind the curtains", VIEWSTATE i cała okolica do "emulacji
WinForms" to dla mnie jest właśnie takie faux pas xD.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.eu/