> Bei einer konsequenten Umsetzung des MVC bietet es sich von daher an, den Destruktor zu nutzen um Änderungen am Modell wieder persistent zu machen. Das könnte man in einem [Active-Record-Modell](https://en.wikipedia.org/wiki/Active_record_pattern) so machen, im Artikel benutzen wir aber ein [Data Mapper](https://en.wikipedia.org/wiki/Data_mapper_pattern)-Modell. Das **Domain**-Model weiß nichts von der Datenbank, es weiß auch nicht, wie es sich zu speichern hätte. Dort macht es also keinen Sinn im Destruktor eine Speicher-Methode aufzurufen. Das **Resource**-Model befindet sich bei uns per Konstruktion immer in einem konsistenten Zustand mit der Datenbank. Bei jedem Aufruf von `fetch` oder `update` wird das betroffene Modell automatisch mit der Datenbank synchronisiert. Hier macht es also auch keinen Sinn im Destruktor nochmal etwas zu speichern, das sowieso schon aktuell ist.

> Bei einer konsequenten Umsetzung des MVC bietet es sich von daher an, den Destruktor zu nutzen um Änderungen am Modell wieder persistent zu machen. Das könnte man in einem [Active-Record-Modell](https://en.wikipedia.org/wiki/Active_record_pattern) so machen, im Aritkel benutzen wir aber ein [Data Mapper](https://en.wikipedia.org/wiki/Data_mapper_pattern)-Modell. Das **Domain**-Model weiß nichts von der Datenbank, es weiß auch nicht, wie es sich zu speichern hätte. Dort macht es also keinen Sinn im Destruktor eine Speicher-Methode aufzurufen. Das **Resource**-Model befindet sich bei uns per Konstruktion immer in einem konsistenten Zustand mit der Datenbank. Bei jedem Aufruf von `fetch` oder `update` wird das betroffene Modell automatisch mit der Datenbank synchronisiert. Hier macht es also auch keinen Sinn im Destruktor nochmal etwas zu speichern, das sowieso schon aktuell ist.

> Bei einer konsequenten Umsetzung des MVC bietet es sich von daher an, den Destruktor zu nutzen um Änderungen am Modell wieder persistent zu machen. Das könnte man in einem [Active-Record-Modell](https://en.wikipedia.org/wiki/Active_record_pattern) so machen, im Aritkel benutzen wir aber ein [Data Mapper](https://en.wikipedia.org/wiki/Data_mapper_pattern)-Modell. Das Domain-Model weiß nichts von der Datenbank, es weiß auch nicht, wie es sich zu speichern hätte. Dort macht es also keinen Sinn im Destruktor eine Speicher-Methode aufzurufen. Das Resource-Model befindet sich bei uns per Konstruktion immer in einem konsistenten Zustand mit der Datenbank. Bei jedem Aufruf von `fetch` oder `update` wird das betroffene Modell automatisch mit der Datenbank synchronisiert. Hier macht es also auch keinen Sinn im Destruktor nochmal etwas zu speichern, das sowieso schon aktuell ist.

> Bei einer konsequenten Umsetzung des MVC bietet es sich von daher an, den Destruktor zu nutzen um Änderungen am Modell wieder persistent zu machen. Das könnte man in einem [Active-Record-Modell](https://en.wikipedia.org/wiki/Active_record_pattern) so machen, im Aritkel benutzen wir aber ein [Data Mapper](https://en.wikipedia.org/wiki/Data_mapper_pattern)-Modell. Das Domain-Model weiß nichts von der Datenbank, es weiß auch nicht, wie es sich zu speichern hätte. Dort macht es also keinen Sinn im Destruktor eine Speicher-Methode aufzurufen. Das Resource-Model befindet sich bei uns per Konstruktion immer in einem konistenten Zustand mit der Datenbank. Bei jedem Aufruf von `fetch` oder `update` wird das betroffene Modell automatisch mit der Datenbank synchronisiert. Hier macht es also auch keinen Sinn im Destruktor nochmal etwas zu speichern, das sowieso schon aktuell ist.