[oop] loading en object in view

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 volgende »

Ozzie PHP

Ozzie PHP

12/05/2014 21:52:32
Quote Anchor link
Hoi allemaal,

Ik heb 2 OOP vragen, die enigszins met elkaar hebben te maken.

1) Loading

Als we een object hebben, bijvoorbeeld een product, dan kunnen we dat product laden met een mapper. Bijvoorbeeld:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
$product_mapper
= new ProductMapper();
$product        = $product_mapper->load(12);
?>

Maar wat als we in plaats van één product bijvoorbeeld de 10 laatste toegevoegde producten willen tonen? Hoe werkt dat dan? Gebruiken we daar diezelfde mapper voor? Ik neem aan van niet, want we gaan niet ieder product stuk voor stuk uit de databse ophalen. Maar hoe dan wel?

2) Object in view

Stel ik heb een product ingeladen, hoe krijg ik dan de productinformatie in de view. Ik heb me ooit eens laten vertellen dat je in een view geen objecten mag gebruiken, omdat een view geen "intelligentie" mag bevatten. Dit zou volgens diegene dus niet mogen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php

echo '<div id="product">' . $product->getName() . '</div>';

?>

Volgens die persoon moet je in de controller de benodigde variabelen doorsturen/beschikbaar maken in de view. Dus zoiets:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
// ProductController

public function show() {
  // product ophalen
  $this->toView('product_name', $product->getName());
}


// view

echo '<div id="product">' . $product_name . '</div>';

?>

Zijn jullie het er mee eens dat je in de view geen objecten maar uitsluitend variabelen mag gebruiken?
Gewijzigd op 12/05/2014 21:52:50 door Ozzie PHP
 
PHP hulp

PHP hulp

29/03/2024 02:26:49
 
Frank Nietbelangrijk

Frank Nietbelangrijk

12/05/2014 22:29:17
Quote Anchor link
ik reageer op vraag twee:

jouw eerste code mag wél. Waar je volgens mij mee in de war bent is het volgende:

je controller roept de view aan:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
// ProductController

public function show() {
    // product ophalen

    $data = array(
        'product' => $product
    );

    $this->toView($data);
}

?>


Je controller geeft alle data door in een array. nu wil je in de view de indexen uit de array omzetten in variabelen.
$data['product'] naar $product zeg maar

dat doe je met de php functie extract: http://nl1.php.net/extract

Toevoeging op 12/05/2014 22:32:24:

wat betreft vraag één verander load() gewoon in

- findAll() // geeft een array van objecten terug
- findOneBy(..) // geeft één object terug (of NULL indien niet gevonden)
- findBy(..) // geeft een array van objecten terug
Gewijzigd op 12/05/2014 22:37:36 door Frank Nietbelangrijk
 
Wouter J

Wouter J

12/05/2014 22:32:34
Quote Anchor link
Ik zie de overeenkomstige factor niet echt, maar goed... :P

Quote:
Maar wat als we in plaats van één product bijvoorbeeld de 10 laatste toegevoegde producten willen tonen? Hoe werkt dat dan? Gebruiken we daar diezelfde mapper voor? Ik neem aan van niet, want we gaan niet ieder product stuk voor stuk uit de databse ophalen. Maar hoe dan wel?

Sinds wanneer kan een mapper alleen stuk voor stuk dingen uit de database halen?

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php

class ProductMapper
{
    public function getLatestProducts($limit = 10)
    {

        $products = [];
        foreach ($this->db->getResult('SELECT name, price, description FROM products ORDER BY release_date LIMIT '.$limit) as $product) {
            $products[] = $this->populate($product);
        }


        return $products;
    }
}

?>
 
Dos Moonen

Dos Moonen

12/05/2014 22:46:16
Quote Anchor link
2)

Views mogen best logica bevatten. De view mag van mij zelfs de content-type bepalen.

Templates wil je het liefst zo min mogelijk logica (en absoluut geen 'business logic') geven. Simpele if/else, while loops en dergelijken zijn prima. (google een naar 'logic less templates')

Houd controllers slank (het liefst niet meer dan 20-30 regels per method, inclusief whitespace en commentaar) en dom.

Models is waar de bulk van je logica zich bevind. Services zoals die mappers, de classes waar naartoe gemapt wordt, utility classes etc.

Views bevatten logica om de door de Model laag aangeleverde ruwe data - denk een ISO8601 geformatteerde datum, of een unix timestamp - op te juiste manier te weergeven - in het Nederlandse dd-mm-yyyy formaat. Daar komt logica aan te pas die niet in het model, maar ook niet in de template hoort.
Of HTML escapen: de Model laag hoort niet te weten hoe de data gebruikt gaat worden, de view wel. Al begint het nu een beetje onduidelijk te worden of je dit in de View of de template wilt hebben...
Gewijzigd op 12/05/2014 22:48:30 door Dos Moonen
 
Ozzie PHP

Ozzie PHP

13/05/2014 00:11:03
Quote Anchor link
@Frank:

>> jouw eerste code mag wél. Waar je volgens mij mee in de war bent is het volgende:

Het probleem is dat als ik een object in een view plaats, ik in principe ook dit zou kunnen doen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
echo '<div id="product">' . $product->getName() . '</div>';
$product->setProperty('foo', 'bar');
?>

Waarom ik dit in een view zou willen doen? Geen idee, maar het zou kunnen en daarom hoorde je geen objecten in een view te zetten aldus die persoon. In een view mag je alleen variabelen zetten. Dus dan zou je dus alle objecten weer moeten omzetten naar een array ofzo?

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
// ProductController

public function showProducts() {
  // producten ophalen
  $products_for_view = array();
  foreach ($products as $product) {
    $products_for_view[]['name']  = $product->getName();
    $products_for_view[]['price'] = $product->getPrice();
    // enz.
  }

}

?>

Dat lijkt me eerlijk gezegd een beetje dubbelop allemaal...

@Wouter:

>> Sinds wanneer kan een mapper alleen stuk voor stuk dingen uit de database halen?

Ah oke.. ik snap wat je bedoelt. Maar gaat de mapper dan niet de taak van het Model (als in MVC) overnemen?

@Dos:

>> Al begint het nu een beetje onduidelijk te worden of je dit in de View of de template wilt hebben...

Kun jij eens uitleggen hoe jij het verschil ziet tussen een view en een template? Ik ken eigenlijk (vanuit de 1e versie van Zend Framework) alleen het begrip view. Een view was dan een stuk HTML code waarin je de variabelen gebruikte die door de controller werden aangeleverd. Eén view was bijvoorbeeld de complete HTML voor een productpagina.
Gewijzigd op 13/05/2014 00:15:11 door Ozzie PHP
 
Frank Nietbelangrijk

Frank Nietbelangrijk

13/05/2014 00:21:18
Quote Anchor link
Ozzie PHP op 13/05/2014 00:11:03:
... en daarom hoorde je geen objecten in een view te zetten aldus die persoon.


Ik weet dat symfony of twig en codeigniter het zo doen. Het alternatief is alles in een array zetten. Beetje omslachtig niet? Bovendien geef je alleen de entities mee naar de view. Niet de mappers. en dan nog de waarde van een array kun je ook veranderen in de view. Nee voor mij geen enkel probleem en nogmaals de grote frameworks doen het zo.
 
Ozzie PHP

Ozzie PHP

13/05/2014 00:59:51
Quote Anchor link
>> Ik weet dat symfony of twig en codeigniter het zo doen.
>> Nee voor mij geen enkel probleem en nogmaals de grote frameworks doen het zo.

Oké, even om alle misverstanden uit de weg te ruimen... met "doen het zo" bedoel je het gebruik van objecten in views, correct?

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
echo '<div id="product">' . $product->getName() . '</div>';
?>
 
Ward van der Put
Moderator

Ward van der Put

13/05/2014 09:13:32
Quote Anchor link
Die laatste oplossing, met directe toegang tot een object in $product->getName(), schaalt niet fijn. Stel dat je de naam van een product wilt gebruiken als een titel en een grote kop in een productpagina. Dan zou je verkort zoiets krijgen:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
<!DOCTYPE html>
<html>
  <head>
    <title><?php echo $product->getName(); ?></title>
  </head>
  <body>
    <h1><?php echo $product->getName(); ?></h1>
  </body>
</html>

Daarmee ligt het ontwerp van de productpagina erg vast — en misschien wel té vast. Bovendien kunnen we de template alleen gebruiken voor een productpagina, niet voor andere soorten pagina's.

Die beperkingen hebben we niet als we er een controller tussen zetten die bepaalt dat $title = $product->getName(). Dan kunnen we $title namelijk ook op iets anders instellen. En dan kunnen we de template ook hergebruiken voor iets anders dan alleen een productpagina:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
<!DOCTYPE html>
<html>
  <head>
    <title><?php echo $title; ?></title>
  </head>
  <body>
    <h1><?php echo $title; ?></h1>
  </body>
</html>


Ozzie PHP op 13/05/2014 00:11:03:
Kun jij eens uitleggen hoe jij het verschil ziet tussen een view en een template? Ik ken eigenlijk (vanuit de 1e versie van Zend Framework) alleen het begrip view. Een view was dan een stuk HTML code waarin je de variabelen gebruikte die door de controller werden aangeleverd. Eén view was bijvoorbeeld de complete HTML voor een productpagina.

Je kunt min of meer zeggen dat een template een vorm van een view is. Meestal gebruik ik één template voor één webpagina (eventueel aangevuld met universele templates voor de masthead, de sitenavigatie en een footer). Daarbinnen kunnen paginaonderdelen echter worden opgebouwd met verschillende views. Een voorbeeld zijn advertenties: wil je drie advertenties weergegeven, dan hergebruik je drie keer hetzelfde onderdeel (drie keer één view) op drie posities in één template (een andere view).
 
Wouter J

Wouter J

13/05/2014 09:17:47
Quote Anchor link
Ward:
En dan kunnen we de template ook hergebruiken voor iets anders dan alleen een productpagina:

Waarom zou je dat willen? Een productpagina en een blogpagina hebben beide een compleet andere lay-out, die krijgen ook mooi hun eigen view. :)

Ozzie:
Maar gaat de mapper dan niet de taak van het Model (als in MVC) overnemen?

De DataMapper is de Model. Dit werkt weer precies zoals het template <> view verhaal. "Model" is de naam van een laag in je applicatie, "DataMapper" is een invulling van die laag. "View" is de naam van een laag in je applicatie, "Template" is een invulling van die laag.
 
Ward van der Put
Moderator

Ward van der Put

13/05/2014 09:26:00
Quote Anchor link
Wouter J op 13/05/2014 09:17:47:
Ward:
En dan kunnen we de template ook hergebruiken voor iets anders dan alleen een productpagina:

Waarom zou je dat willen? Een productpagina en een blogpagina hebben beide een compleet andere lay-out, die krijgen ook mooi hun eigen view. :)

Als jij het okay vindt dat www.example.com een compleet andere lay-out heeft dan www.example.com/blog, dan is dat jouw persoonlijke ontwerpbeslissing. Over smaak valt niet te twisten :-)
Gewijzigd op 13/05/2014 09:38:34 door Ward van der Put
 
Wouter J

Wouter J

13/05/2014 09:54:02
Quote Anchor link
>> Over smaak valt niet te twisten :-)
Lay-out gaat niet over smaak, dat is design :) Kijk alleen naar deze site. Deze forum topic pagina is toch qua lay-out anders dan een tutorial pagina of de nieuws pagina?
 
Ward van der Put
Moderator

Ward van der Put

13/05/2014 10:06:01
Quote Anchor link
Correct, maar er zijn ook overeenkomsten tussen alle pagina's. Strikt genomen zou je daarom de overeenkomsten ergens anders moeten onderbrengen dan de verschillen.

De vraag van Ozzie naar verschillen en overeenkomsten tussen templates en views is daarom wel een interessante.

Persoonlijk vind ik overigens ook dat de term template vaak verkeerd wordt gebruikt, want bijvoorbeeld "templates" die je voor open-source CMS'en en blogtools kunt downloaden of kopen, zijn vaak meer skins dan echte templates. Als je het design kunt veranderen door een ander CSS-bestand te gebruiken, dan is dat een skin, geen template.
 
Jacco Engel

Jacco Engel

13/05/2014 10:20:13
Quote Anchor link
Wat mij vooral opvalt als ik het zo doorlees is dat iedereen bij een template direct aan een volledige pagina denkt.

Ik vind het persoonlijk bevoorbeeld wel prettig om mijn pagina in secties in te delen (menu header content om het even simpel te houden), en dan 3 templates te schrijven die ik elk binnen 1 pagina los inlaad.
 
Wouter J

Wouter J

13/05/2014 10:36:20
Quote Anchor link
>> Wat mij vooral opvalt als ik het zo doorlees is dat iedereen bij een template direct aan een volledige pagina denkt.

Dat valt mij inderdaad ook op :)

Ward, de overeenkomstige elementen breng je onder in een "parent" template. De verschillen in andere templates. Even een Twig voorbeeldje:
Code (layout.html.twig) (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
<!doctype html>
<html ...>
<head>
    <title>{% block title %}{% endblock %} - PHPhulp</title>
</head>
<body>
    <header>...<header>
    <div id="page__main">
        {% block main %}{% endblock %}
    </div>
    <footer>...</footer>
</body>
</html>

Code (topic.html.twig) (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{% extends 'layout.html.twig' %}

{% block title %}{{ topic.title }}{% endblock %}

{% block main %}
    <article>
        <h1>{{ topic.title }}</h1>
        <p>{{ topic.content }}</p>

        <ul>
            {% for comment in topic.comments %}
            <li>
                <article>
                    <h1>{{ comment.author }}</h1>
                    <p>{{ comment.content }}</p>
                </article>
            </li>
            {% endfor %}
        </ul>
    </article>
{% endblock %}

Code (tutorial.html.twig) (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
{% extends 'layout.html.twig' %}

{% block title %}{{ tutorial.title }}{% endblock %}

{% block main %}
    <article>
        <h1>{{ tutorial.name }}</h1>
        <p>{{ tutorial.description }}</p>

        <nav>
            <ul>
                {% for page in tutorial.page %}
                <li><a href="{{ page.link }}">{{ page.title }}</a></li>
                {% endfor %}
            </ul>
        </nav>

        <aside>
            <h1>Comments</h1>
            <ul>
                {% for comment in tutorial.comments %}
                    {# ... #}
                {% endfor %}
            </ul>
        </aside>
    </article>
{% endblock %}
Gewijzigd op 13/05/2014 10:36:38 door Wouter J
 
D Vivendi

D Vivendi

13/05/2014 11:29:06
Quote Anchor link
Ozzie PHP op 13/05/2014 00:11:03:
Het probleem is dat als ik een object in een view plaats, ik in principe ook dit zou kunnen doen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
echo '<div id="product">' . $product->getName() . '</div>';
$product->setProperty('foo', 'bar');
?>


Het "originele" object moet je niet doorgeven aan je view. Daar heb je dan ook ViewModels voor.

En ViewModels mogen gewoon objecten bevatten (andere ViewModels) or array en dergelijke. Daar is niets mis mee.
 
Ozzie PHP

Ozzie PHP

13/05/2014 17:40:15
Quote Anchor link
Dankjulliewel voor de vele reacties. Ik ga even proberen een paar puntjes aan te stippen.

@Ward:

Ik begrijp jouw voorbeeld met $title. Ik neig dan echter naar de oplossing van Wouter, waarbij je gebruik maakt van een "master" view, waar al een titel in is verwerkt. En dan zou je zelfs vanuit de controller een aparte functie kunnen hebben om een titel in te stellen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
$this
->setTitle($product->getName());
?>

Maar er komt een punt op de pagina waar je iets specifieks (een product, een nieuwsbericht, een user enz.) wil uitwerken. Stel je hebt bijvoorbeeld een overzicht met de 10 laatste toegevoegde Users. Iedere User heeft een naam. Dan staan er dus 10 namen op je scherm, en die namen zijn natuurlijk geen titels. Haal je zo'n naam nu direct uit het originele User object is dan mijn vraag?

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
foreach ($users as $user) {
  echo $user->getName();
}

?>

Is dat correct?

@Wouter:

>> De DataMapper is de Model. Dit werkt weer precies zoals het template <> view verhaal. "Model" is de naam van een laag in je applicatie, "DataMapper" is een invulling van die laag. "View" is de naam van een laag in je applicatie, "Template" is een invulling van die laag.

Oké. Het lastige vind ik dus om te begrijpen hoe dit er in de code (even heel versimpeld) uitziet. In Zend Framework 1.0 kreeg je zeg maar zoiets:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php

// FooController.php

public function showFoo() {
  $foo_model = new FooModel();
  $foo       = $foo_model->getFoo();
  $this->toView('name'       , $foo->getName());
  $this->toView('description', $foo->getDescription());
  $this->renderView('foo_view');
}


// foo_view.phtml

echo '<div id="foo">';
echo $name . '<br><br>' . $description;
echo '</div>';

?>

Je had dan dus eigenlijk 3 bestanden:
- FooController.php
- FooModel.php
- foo_view.phtml

Hoe ziet deze opzet er dan uit met een mapper en een template? Blijft dat gewoon hetzelfde, maar noem je het FooModel.php nu ineens FooMapper.php?

@D Vivendi:

>> Het "originele" object moet je niet doorgeven aan je view. Daar heb je dan ook ViewModels voor.

Die opzet ken ik niet. Kun je aub een voorbeeldje geven?
Gewijzigd op 13/05/2014 17:41:35 door Ozzie PHP
 
Frank Nietbelangrijk

Frank Nietbelangrijk

13/05/2014 17:58:46
Quote Anchor link
Ozzie PHP op 13/05/2014 00:59:51:
Oké, even om alle misverstanden uit de weg te ruimen... met "doen het zo" bedoel je het gebruik van objecten in views, correct?


Correct Ozzie.
 
Wouter J

Wouter J

13/05/2014 18:13:15
Quote Anchor link
>> Kun je aub een voorbeeldje geven?

Als we het heel domain driven aanpakken gebruik je DTO's (Data Transer Objects) om tussen verschillende lagen te communiceren. Voor applicatie -> view gebruik je hiervoor ViewModels:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?php
class PostViewModel
{
    private $title;
    private $content;

    public function __construct($title, $content)
    {

        $this->title = $title;
        $this->content = $content;
    }


    public function getTitle()
    {

        return $this->title;
    }


    public function getContent()
    {

        return $this->content;
    }
}

?>

Voor je template zet je je Page entity dus om in een PageViewModel.

Toevoeging op 13/05/2014 18:47:26:

Maar merk op dat Domain Driven Development op dit niveau alleen maar leuk wordt als je echt met grote complexe projecten gaat werken. Voor bijna alle gevallen is dit veel te overdreven, zeg je even KISS en You Aint Gonna Need It en gooi je gewoon je entity in de view.




>> Blijft dat gewoon hetzelfde, maar noem je het FooModel.php nu ineens FooMapper.php?

Het grappige is dat een FooModel eigenlijk al een DataMapper is. Alleen noem je het Model, omdat Zend je nou eenmaal ooit heeft geleerd het Model te moeten noemen.
Gewijzigd op 13/05/2014 19:52:11 door Wouter J
 
D Vivendi

D Vivendi

13/05/2014 20:14:39
Quote Anchor link
Ik weet zelf niet of het voorbeeld van Wouter helemaal juist is. Ik zou persoonlijk ook niet kiezen voor een ViewModel waar ik dingen doorgeef via de constructor. Ik zou gewoon de properties public maken en die direct setten. Ik ken ViewModels ook meer uit MVC.NET en die manier pas ik ook weer toe in mijn PHP code.

In .NET is het bijvoorbeeld zo dat elke view zijn eigen Model/ViewModel heeft. Zelfs partial views.

Zo'n ViewModel is niets meer dan slechts een simpele class met de properties die jij beschikbaar wilt stellen aan je view.

Bijvoorbeeld:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
<?php
class SimpleProductViewModel
{
    public $naam;
    public $prijs;
}

?>


Als je alleen die twee properties wilt tonen uit de hele lijst properties die komen uit je "ProductModel" class.

Je ViewModel set je in je controller method.

Overigens zou ik helemaal geen ViewModels of wat voor php objecten dan ook aan mijn view mee willen geven. Ik zou alles liever via REST doen. Maar goed, dat is dan weer een ander verhaal denk ik.

Als je echt meer over view models in .NET wilt weten zou ik gewoon even op youtube wat tutorials bekijken. Dat is denk ik de beste manier om hierover een heldere uitleg te krijgen.
 
Wouter J

Wouter J

13/05/2014 20:22:47
Quote Anchor link
>> Ik zou persoonlijk ook niet kiezen voor een ViewModel waar ik dingen doorgeef via de constructor. Ik zou gewoon de properties public maken en die direct setten.

Hier heb ik ook over gedacht. Voor Command objects doe ik dit namelijk vaak wel :) Maar hierdoor raak je in je View wel een beetje beveiliging kwijt: De view kan de data aanpassen. En goed, de view kan alleen de data op view level aanpassen en niet op applicatie level, maar toch je hebt de ViewModel gemaakt om een immutable object te hebben.
 
Ozzie PHP

Ozzie PHP

13/05/2014 20:26:53
Quote Anchor link
@Frank:

>> Correct Ozzie.

Oké, thanks ;)

@Wouter:

>> Het grappige is dat een FooModel eigenlijk al een DataMapper is. Alleen noem je het Model, omdat Zend je nou eenmaal ooit heeft geleerd het Model te moeten noemen.

Oké... dus Model en Mapper zijn gewoon hetzelfde?

In je voorbeeld heb je het over een PageViewModel en in het codevoorbeeld over een PostViewModel. Is een van beide een verspreking?

Ik snap alleen nog niet hoe het werkt zo'n DTO. Stel je wil een aantal producten tonen. Is dan de bedoeling dat de productgegevens uit de database haalt? Dat je hier normale productobjecten van maakt, en dat je dan vervolgens aan de hand van deze objecten een array gaat maken met speciale ProductViewModels, die in feite hetzelfde zijn als de normalen Product objecten, maar dan zonder setters? Begrijp ik het dan goed?

En jij geeft zelf al aan dat je KISS zou toepassen. Jij bent dus ook voorstander om gewoon de productobjecten zelf in een view te gebruiken?

>>Hier heb ik ook over gedacht. Voor Command objects doe ik dit namelijk vaak wel :) Maar hierdoor raak je in je View wel een beetje beveiliging kwijt: De view kan de data aanpassen. En goed, de view kan alleen de data op view level aanpassen en niet op applicatie level, maar toch je hebt de ViewModel gemaakt om een immutable object te hebben.

Maar als ik een normaal Product object in mijn view gebruik, dat kan ik toch in de view via de setter methods toch ook de data aanpassen? Of begrijp ik het nu verkeerd?

@D Vivendi:

Oké... ik vraag me af, wat jij noemt een ProductModel noem ik volgens mij gewoon een Product class (die in mijn library staat). Waarom noem je dat een model?
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.