Model, Controller, View oder Helper?
Die Kommentare zu diesem Post stellen eine Diskussion über die Funktionen der Hauptbereiche von Ruby on Rails dar. Das Ergebnis wird dann hier zusammengefasst.
Es ist auch klar, dass die Unterteilung der Bereiche nicht eindeutig ist, aber vielleicht finden wir eine gute Tendenz.
Ähnliche Posts:
Railscasts.com – die beste Ruby on Rails Resource
HowTo: Ruby on Rails via MacPorts (aka DarvinPorts) unter Mac OS X
FINALLY! RailsICalendar ical ics publish with ruby on rails![ÜÄÖß Umlaute kaputt in Ruby on Rails und MySQL [broken umlauts]](http://funkensturm.de/wp-content/plugins/related-posts/static/thumbs/15.jpg)
ÜÄÖß Umlaute kaputt in Ruby on Rails und MySQL [broken umlauts]
Rails 2.2: NoMethodError von create_time_zone_conversion_attribute?
Ich heiße Captain Future und meine Leidenschaft ist es die Brücke zwischen Menschen und Technik zu schlagen.
Vielleicht vorweg: Ich habe die Erfahrung gemacht, dass z. B. im Helper oder im Model bestimmte Funktionen gar nicht verfügbar sind.
Wenn du z. B. in deinem Controller eine Funktion “def authorize” hast, um zu überprüfen, ob der Anwender etwas aus der DB lesen darf, kannst du diese Funktion im Model gar nicht aufrufen. Es widerspräche ja der Abschottung von Informationen gegenüber der Bereiche, obwohl es logisch “scheint”, dass das Model checken soll, ob es Informationen preisgeben darf oder nicht. Das kann es übrigens manchmal auch nicht, da die session z. B. gar nicht im Model verfügbar ist.
Also es gibt da noch ein paar Details über die ich nicht im Bilde bin. Vielleicht findet mal jemand eine Übersicht, welche Art von Variablen wo verfügbar sind und wie man es machen sollte.
haha danke future! genau die probleme hatte ich auch… wir haben einfach bis her zu wenig OOP gemacht…
Hier mal zur Einleitung nen guter Railscast: Custom Helper Modules
aber das ganze sollte man mal wirklich für PHP Umsteiger aufdrösseln und dann gesammelt fest halten.
hi,
das hat schon alles seine Richtigkeit, dass Controller Methoden nicht im Model verfügbar sind. ;)
MVC – ansonsten müsste die Bereiche ja nicht aufteilen.
z.B. Code der prüft ob ein User etwas darf oder nicht ist Logik und gehört somit in den Controller. Im Model gehts nur um Daten und die Schnittstelle zur Datenbank.
Man kann sagen, dass das Model der reinen Datenbanktabelle eine gewisse Intelligenz verleiht. (z.B. berechnungen, etc.)
Im Controller steckt die Businesslogik und er verarbeitet die User-Anfragen, verändert Daten/Models und rendert den entsprechenden View aus.
Im View sind dann nur HTML code. (hier sollte nur auf Variablen zugegriffen werden die der Controller bereitstellt.)
für PHP Umsteiger ist das manchmal schwer. weil die meisten in PHP ohne patterns und nicht objektorientiert Programmieren.
Wenn man an solche “Probleme” stößt sollte man immer erst überlegen wieso das so ist. Meistens ist es kein “Problem” sondern ein Feature.
ok aber wieso sagen dann einige, dass sie die controller ganz klein lassen und alles ins model auslagern? für mich gibt es da zu viele theorien und als php umsteiger bin ich da echt ein wenig überfordert :-D
freu mich aber die ganzen features kennen zu lernen!
hier noch was zum thema:
http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model