Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Model beim MVC Pattern richtig anwenden

Werbeanzeige

Garzec

Alter Hase

  • »Garzec« ist der Autor dieses Themas

Beiträge: 693

Wohnort: Gießen

  • Private Nachricht senden

1

27.12.2017, 15:55

Model beim MVC Pattern richtig anwenden

Hallo,
ich möchte gerne mit NodeJs das MVC Pattern verwenden. Mal angenommen, ich verwende diesen simplen Code

Quellcode

 
1
2
3
4
5
6
7
8
9

const model = require('./model');

module.exports = function(app){

app.get('/myRoute', function (req, res) {
    res.render('myTemplate', model()); // Hier lasse ich mir die benötigten Daten vom Model zurückliefern
});

};


und das Model selbst hat nur

Quellcode

 
1
2
3

module.exports = function(){
  return {};
};


Jetzt kommt der erste Ajax Call hinzu, der sich ebenfalls Daten am Server holen muss

Quellcode

 
1
2
3
4

app.post('/myRoute/getSomeData', function (req, res) {
    var data = req.body;
    res.send({}); // irgendwelche Daten zurückliefern
});


Was mache ich jetzt mit meinem Model? Lege ich ein weiteres Script an, mit einem anderen Model?

Möglich wäre ja solch eine Konstellation

Quellcode

 
1
2
3
4
5
6
7
8
9

module.exports = {
  loadRouteData: function(){
    return {};
  }

  getSum: function(valOne, valTwo){
    return valOne + valTwo;
  }
};


Wobei ich dann beim Rendern diesen Code nehme

Quellcode

 
1

res.render('myTemplate', model.loadRouteData());


und beim Ajax Call diesen Code

Quellcode

 
1

res.send(model.getSum(11, 27));


Aber macht man das so? Gibt es da elegantere Wege?

Julién

Alter Hase

Beiträge: 717

Wohnort: Bayreuth

Beruf: Student | Hilfswissenschaftler in der Robotik

  • Private Nachricht senden

2

09.02.2018, 01:17

(An die Erfahrenen: Es ist spät, wenn ich Mist erzähle, dann korrigiert mich bitte.)

Ein Model enthält lediglich Daten, die vom Program verarbeitet werden.
Im Prinzip kann eine Liste, eine Map/Dictionary oder eine Klasse sein.
Letzteres erweist sich meist als angenehmsten beim verwenden.

Angenommen wir arbeiten an einer einfachen Userverwaltung, dann würde unser Model so aussehen:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class User{
    constructor(name, hashed_password){
        this.name = name;
        this.hashed_password;
    }

    set_name(name){
        this.name = name;
    }

    get_hashed_password(){
        return this.hashed_password;
    }

    set_hashed_password(hashed_password){
        this.hashed_password = hashed_password;
    }
}


Das wäre schon ein einfaches Model. Wie gesagt, ein Model soll NUR Daten enthalten, keine Logik.

Zitat


Was mache ich jetzt mit meinem Model? Lege ich ein weiteres Script an, mit einem anderen Model?


Side note:

Zitat

Bei deiner Frage sehe ich eher ein Problem bei deiner Arbeitsweise. Hast du denn ein konkretes Problem,
dass du mit dem MVC lösen möchtest?
Man sollte keine Pattern verwenden, nur weil sie 'fancy' sind, sondern dann wenn sie gebraucht werden.

Kennst du die Bedeutung eines Models außerhalb des MVCs?
Ein Model stellt, grob definiert, ein Objekt aus der Realität dar. In der Programmierung verwenden wird Klassen um Objekte zu "repräsentieren".

Was heißt das?
Das heißt, dass du für jedes Objekt, dass du im Code repräsentieren möchtest eine eigene Klasse (sprich Model) schreibst.
Ob du für jeder Klasse eine eigene Skriptdatei schreibst oder nicht, das bleibt dir überlassen, würde sich jedoch anbieten.

Weiter Sidenote:

Zitat


Recherchiere die Begriffe "RESTful API" und "CRUD". Wenn du die Parallelen entdeckt und verstanden hast, dann schreibt sich eine Webapp mit MVC-Architektur schon fast von alleine.


P.S.: Man verwendete POST-Requests nicht um Daten abzufragen. Dafür hat man GET-Requests.
I write my own game engines because if I'm going to live in buggy crappy filth, I want it to me my own - Ron Gilbert

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Julién« (09.02.2018, 01:38)

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

3

09.02.2018, 06:30

Zitat von »Julién«

Das wäre schon ein einfaches Model. Wie gesagt, ein Model soll NUR Daten enthalten, keine Logik
Das stimmt so nicht. Natürlich hat ein Modell auch eigene Logik, sonst reden wir hier nicht über MVC, sondern über Data Oriented wie z.B. ECS. MVC stellt nur sicher, dass Änderungen am Modell durch einen Controller erledigt werden und eine View nicht direkt darauf herum fummelt und View-Änderungen ebenfalls durch den Controller gehen, statt vom Modell ausgeführt zu werden. Ein Modell darf aber natürlich sehr wohl seine eigene Logik enthalten. Z.B. "Bibliothek.verleiheBuchAn(Kunde)" ist eine absolut legale Modell-Operation. Sie verändert aber erstmal den View nicht, weil der ja entkoppelt davon ist.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »BlueCobold« (09.02.2018, 06:36)

Chromanoid

Alter Hase

Beiträge: 1 410

  • Private Nachricht senden

4

09.02.2018, 16:01

Ich finde das MVC-Pattern meist sehr hölzern und beliebig. Es kommt sehr auf den Stil der Programmierer an, wie das ganze dann am Ende aufgeteilt wird. Sieht man an den Beiträgen oben ja sehr schön.

Ich stimme da BlueCobold zu, obwohl ich der Interpretation des Models von Julien ebenfalls schon oft begegnet bin.

Ich stand schon oft genau vor dem gleichen Abtrennungsproblem. Seit dem ich mehr mit dem MVVM-Pattern gearbeitet habe, fällt mir die Auftrennung aber viel leichter. Beim MVC-Pattern ist das Model aus meiner Sicht eher mit dem ViewModel aus dem MVVM-Pattern zu vergleichen, also einem Model für die View. Der Controller sorgt dann für die Verknüpfung von View und Model. Er übernimmt sozusagen das, was beim MVVM-Pattern über Data-Binding gelöst wird. D.h. ich finde den Aufbau so am sinnvollsten: Persistenz -> Backend-Model -> Frontend-(View)Model -> Controller -> View

Wenn man da jetzt noch Systemgrenzen einzieht könnte es auch so aussehen:
[Persistenz -> Backend-Model]--[Data-Transfer-Model (JSON o.Ä.)]-->[Frontend-(View)Model -> Controller -> View]
Wobei der rechte Teil (Frontend) ggf. vollständig im Browser ablaufen kann - oder bei serverseitigem Templating/Rendering käme rechts dann noch mal ein bisschen was dazu.

Zur Faustregel kann man sich machen, der Controller kennt nur das Model und die View. Der Controller sorgt dafür, dass Werte aus dem Model in die Textbox kommen und wieder zurück. Er sorgt dafür, dass beim Knopfdruck in der View im Model "speichern" ausgelöst wird usw.

Wenn Du auch in Richtung Rich-Internet-Application und clientseitigem "Rendering"/Templating gehen willst, kann ich nur empfehlen mal sowas wie vue.js auszuprobieren. Dort setzt man sowas in der Richtung wie das MVVM-Pattern ein.

Noch ein Nachtrag: An sich bin ich gesamtarchitektonisch immer für eine Zwiebelarchitektur.
Besucht auch mal ZFX + Developia: Forum für Spieleentwicklung & TIGSource Forums: Independent Gaming Discussion

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Chromanoid« (09.02.2018, 16:20)

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

5

09.02.2018, 17:55

Zitat von »Chromanoid«

Ich stimme da BlueCobold zu, obwohl ich der Interpretation des Models von Julien ebenfalls schon oft begegnet bin.
Das hängt auch sehr von der konkreten Anwendung ab. Ein Shopsystem hat z.B. erstaunlich wenig aktive Modelle, da ist alles irgendwie ja nur ein Daten-Container. Aber bei einer Simulation, einem Spiel oder irgendwas interaktivem, tun die Modelle durchaus auch selbst etwas und enthalten Logik, die da auch absolut hin darf und hin sollte. Business-Logik gehört letztlich bitte weder in die View, noch in den Controller (wahlweise ViewModel), soweit das geht.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

h_dev

Frischling

Beiträge: 49

  • Private Nachricht senden

6

10.04.2018, 21:53

Das Model liefert dir die Daten. Ob die aus einer Datenbank kommen oder von einem Webservice ist deinen Anforderungen überlassen. Bitte das Model im MVC Pattern nicht mit den Datenmodell, also dem, was sich z.B. in der Datenbank befindet verwechseln. Es ist das logische Modell, kann also nicht nur, sondern muss Logik beinhalten. So kommen die daten dann zum Controller, der zwischen logischem Modell und View vermittelt. Trivial gesagt wäre das dann "Klick auf Button ruft Methode X in Modell Y auf".

Um des Threaderstellers Frage zu beantworten: Wäre der Sinn deiner Anwendung ein Taschenrechner sein, könnte das Modell die Logik selbst implementieren, eine Additionsmethode einer Math library oder einen Webservice aufrufen.

Das von BlueCobold genannte Shopsystem wird auch Logik im Modell haben, allerdings wird die eher Langweilig sein, da es sich eher um CRUD handelt. Daher machen sich viele auch nicht die Mühe, das "M" zu implementieren, sondern schreiben den Code im Controller. Das ist dann aber auch kein MVC Pattern mehr, sondern tendiert zum beliebten und oft verwendeten Spagetticode-Pattern.

Werbeanzeige

Ähnliche Themen