[WEB] MVC = (M = DB, V = Browser, C = PHP/Python/C++/etc.)

[DJMaze]

Ik kwam deze stelling laatst tegen en snap hem wel.
Maar maakt dat niet het hele gedoe van evangelisten dat je een "MVC framework" moet gebruiken in 1 klap monddood?

[sig69]

Nee, dat is nogal kort door de bocht. MVC staat voor model view controller. Het model kan veel meer zijn dan een database, de controller kan je in elke taal schrijven die je wil en je view hoeft niet per se een browser te zijn.

[ Voor 7% gewijzigd door sig69 op 28-07-2016 13:35 ]

[DJMaze]

Precies, maar waarom zie ik dan MVC frameworks zoals:

• AngularJS
• YII
• Sails.js
• Zend
• etcetera

En die laden dan voor een actie 3 bestanden in: model.ext, view.ext, controller.ext

Met de stelling die ik tegen kwam kan het dus ook met 1 bestand (bijvoorbeeld "actie.ext") en je kan dan nog steeds zeggen dat je MVC toepast.

[Cyphax]

Het blijft een patroon, een implementatie daarvan kan natuurlijk op verschillende manieren. Iemand kan best een manier bedenken die je in de titel beschrijft en dat kan best voldoen aan het idee achter MVC.
Wil niet zeggen dat het ook de beste implementatie is en dat een MVC framework het niet beter doet.

[Lye]

Op deze manier zit je wel met gigantische fat controllers, waarbij de businesslogica compleet in de controller zit (immers, het model is alleen een database). Persoonlijk heb ik liever een duidelijkere scheiding, waarbij de controller alleen verantwoordelijk is voor wat ie moet doen: het afhandelen van input en daarmee het model zo manipuleren dat er bruikbare data uitkomt.

Het model zien als "alleen" een database limiteert je gigantisch in het MVC model (ik vraag me oprecht af of je dan nog wel kunt spreken van een echte MVC implementatie). Naar mijn mening hoort een controller niet eens te weten dat een model een database gebruikt. Dat is ook het sterke punt van het MVC model, de verschillende lagen zijn zo opgedeeld dat je deze in de achtergrond compleet kunt veranderen zonder dat er iets veranderd aan de voorkant. Neem bijvoorbeeld een ORM-implementatie. De data-objecten hier zijn onderdeel van het model, maar moet de controller weten dat hier een complete SQL database aan hangt? Na enkele refactorrondes kan het ook prima aangepast worden naar een document store, zonder dat er voor de controller ook maar iets veranderd is.

MVC is geen must, het is absoluut geen heilige graal en zoals Cyphax al zei, het blijft een patroon. Het gaat er vooral om dat je eens goed nadenkt hoe je je code scheidt (seperation of concerns) en een opdeling in een view-, controller- en modellaag maken het over het algemeen vaak makkelijker (in het geval van een webapplicatie).

[Creepy]

Met de stelling die ik tegen kwam kan het dus ook met 1 bestand (bijvoorbeeld "actie.ext") en je kan dan nog steeds zeggen dat je MVC toepast.

Je database is geen model, en je browser is geen view binnen het MVC design pattern. Zeggen dat dat wel zo is en dat je "dus" MVC toepast is echt onzin. Lees Wikipedia: Model-view-controller-model maar eens door bijv

[SPee]

DJMaze schreef op donderdag 28 juli 2016 @ 13:49:
Precies, maar waarom zie ik dan MVC frameworks zoals:

• AngularJS
• YII
• Sails.js
• Zend
• etcetera

En die laden dan voor een actie 3 bestanden in: model.ext, view.ext, controller.ext

Met de stelling die ik tegen kwam kan het dus ook met 1 bestand (bijvoorbeeld "actie.ext") en je kan dan nog steeds zeggen dat je MVC toepast.

Het ligt eraan hoe je dit bekijkt. Je stelling gaat op, op heel globaal niveau. Maar het wordt ook op onderliggende nivo's toegepast.
Je kan op je DB namelijk ook een MVC pattern toepassen, evenals op je serverside programmatuur en (nu steeds vaker) ook clientside.
Het MVC is puur gezien het uit elkaar trekken van Data (input), Logica en Output. Ja, dat kan heel globaal. Je ziet dit b.v. in de plaatjes van de architect. Maar door het decennia lang gebruik is dit gaan verwijzen hoe de serverside applicatie intern werkt. Maar nu met de opkomst van de clientside frameworks als angular.js geldt dit ook vaker voor clientside.

Het lijkt mij echter wel iets waar je een optimum voor moet vinden. En dat hangt ook van het systeem dat je ontwikkelt af.

[Lethalis]

DJMaze schreef op donderdag 28 juli 2016 @ 13:49:
Met de stelling die ik tegen kwam kan het dus ook met 1 bestand (bijvoorbeeld "actie.ext") en je kan dan nog steeds zeggen dat je MVC toepast.

Architecturele patterns zoals MVC zijn er om verantwoordelijkheden te scheiden. Code wordt er doorgaans niet korter of simpeler van, maar het doel is dat men de code in delen opsplitst die afzonderlijk van elkaar te testen en ontwikkelen zijn.

Het is dus vooral van belang als je aan grotere projecten werkt met meerdere mensen. Zo kan de frontend ontwikkelaar zich lekker met de view en het grafische werk bezighouden, terwijl de backend ontwikkelaar met het model en de controllers bezig is.

Ook kan je automatische tests schrijven die door een CI server dagelijks worden uitgevoerd. Zodra iemand ergens iets in een project van een miljoen regels iets verkloot, dan komt dat meteen in beeld dan.

Dat betekent dus niet dat je een pattern lukraak maar overal moet toepassen.

Je moet de voor- en nadelen afwegen.

Als het enige dat jij moet doen bestaat uit een stukje code van 25 regels ofzo, dan is het de overhead niet waard.

Maar bij een groter project is het wel verstandig.

[DJMaze]

Dat begrijp ik ook en ik zie het vaak in een structuur zoals:

/models/user.ext
/controllers/user.ext
/views/user.ext

Maar het kan ook zoals het volgende ook al zie ik dat niet zo vaak:

user/model.ext
user/controller.ext
user/view.ext

En in software (non-web) als:

forms/user.cpp
forms/user.h
forms/user.ui

In beide (web) gevallen is er een probleem met "view.ext", want welk output formaat is dat?
Ik zou dan eerder denken aan:

user/view.ical.ext
user/view.html.ext
user/view.xml.ext
user/view.rss.ext
etc.

De huidige MVC frameworks lijken dus een probleem te hebben (nog maar te zwijgen of model/controller customization per klant).

[ Voor 6% gewijzigd door DJMaze op 31-07-2016 20:52 ]

[Lethalis]

Die scheiding is er omdat models en controllers ook daadwerkelijk in aparte libraries kunnen zitten.

Dat van die extensie is meestal wel duidelijk toch? Bij MVC frameworks is dat html of juist een extensie die bij de view engine hoort.

Cshtml beschrijft een Razor view, sshtml een Super Simple view (Nancy), enzovoort. Output is vrijwel altijd html, omdat rss of xml bijv geen 'view' is.

Een view beschrijft een user interface.

Non-web kies je al gauw voor een MVVM achtige oplossing.

Models en controllers customization per klant? Dit kun je vaak oplossen met interfaces en diverse GoF design patterns.

Maar wellicht kun je beter met een concreet voorbeeld komen

[ Voor 35% gewijzigd door Lethalis op 31-07-2016 21:30 ]

[Ed Vertijsment]

MVC kan zoveel zijn. Traditioneel is natuurlijk een (data)model een database, een view een HTML template (iig in web development) en een controller de <insert random backend language here> laag die tussen de twee andere lagen communiceert.

Met de komst van frontend MVC frameworks (Angular/Aurelia etc...) zie je het zelfde patroon compleet in de browser draaien, maar dan is er opeens geen database meer (IndexedDB tellen we voor het gemak even niet mee). Toch, is er nog steeds sprake van MVC.

Het model in een "single page application" is vaak een laag die met een REST API communiceert. De controller is dan een JavaScript bestandje die de DOM update. MVC is dus anders geïmplementeerd.

MVC beschrijft eigenlijk niets meer dan het onderscheid tussen de informatie, presentatie en de aansturende logica, en dit kun je op veel verschillende manieren toepassen/interpreteren.

Neem nu bijvoorbeeld een statische, simpele HTML website met een beetje CSS en JavaScript. In De HTML staat de informatie die je wilt presenteren (model). Je CSS bestand beschrijft hoe die gepresenteerd wordt (view), en je JavaScript bevat nog wat aansturende logic (controller). Dit is misschien wat vergezocht/doorgetrokken maar in principe nog het zelfde patroon. CSS is immers in het leven geroepen om stijl gerelateerde informatie (zoals <font>) uit de HTML te trekken. En hoevaak zien we niet jQueryjes die simpel classes aan HTML toewijzen?

[Ventieldopje]

Model is ook geen database maar een abstractie laag tussen de controller en de data bron (orm / dbal / rest api etc.). Database is lang niet altijd aan de orde. Afaik is dat altijd al zo geweest toch?