Bild und Text kombiniert verschachteln

[Rolf B]

Hallo MB,

das ist jetzt ziemlich viel geworden, und ich kann kaum auf jeden Punkt einzeln eingehen. Du darfst jedenfalls gern anderer Meinung sein wie ich.

Vererbung scheint mir hier nicht zur Lösung beizutragen. Ok warum? wen keine Vererbung, wie denn dann wenn nicht so?

Es ging mir hier um die Frage, wie man ArtikelModel und TListing zusammenbringt. Das heißt nicht, dass Du generell die Finger von Vererbung lassen sollst.

Entkoppelung? Hier schwer zu realisieren…

Entkoppelung ist immer schwerer zu realisieren als Objekte, die sich ihre Bezugsobjekte eben mal selbst beschaffen. Aber beschäftige Dich mal mit der Idee des Unit Testing, und Du wirst es hassen, dass in ArtikelModel ein new Irgendwas() steht, wenn Du eigentlich nur das Model testen willst und das Irgendwas-Objekt viel lieber durch einen vereinfachten Test-Stub^[1] ersetzen möchtest. Insbesondere Repositories, die die Daten beschaffen, werden bei Unit Tests gerne durch Testexemplare substituiert, um definierte Objekte ohne DB-Abhängigkeit zu haben.

Natürlich musst Du immer schauen, was für Dich passt. Aber in einer Anwendung von mir habe ich eine statische Klasse Context gemacht, die eine statische Eigenschaft $Controllers hat. Darin liegt die Controller-Factory, und einen Controller bekommst Du z.B. mit Context::$Controllers->getArticleController(). Die Factory übergibt automatisch eine Referenz auf die Repository-Factory - und ein Controller, der das nicht annimmt, geht kaputt weil der abstrakte Controller das Ding im Konstruktor haben will.

class Controller {
   protected $Repositories;
   protected function __construct(RepositoryFactory $rep) {
      $this->Repositories = $rep;
   }
}
class ArticleController extends Controller {
  public function __construct($repFac) {
    parent::__construct($repFac);
    $this->model = $this->Repositories->getArticleRepository()->newArticleModel();
  }
}
class ArticleModel extends Model {
  public function __constructor(ArticleRepository rep) {
    $this->repository = rep;
  }
}

ABER: Das ist jetzt eine ganz andere Komplexitätsstufe, und wenn Du eh schon am fluchen bist, hilft Dir das vermutlich nicht weiter. Die wichtigste Waffe im Kampf gegen das "Ich kapier's nicht mehr" ist strukturieren. Divide et impera!

Ein Builder war nur eine Idee falls das Aufbauen von Models umfangreicher ist. Dann möchte man das gerne irgendwohin auslagern.

Mit Business Domain meine ich eine Gruppe von Tables, die zusammengehören. Eine davon ist dann typischerweise die Haupt-Table, die anderen enthalten abhängige Daten, und werden immer zusammen mit der Haupt-Table gelesen, bzw. über ein Objekt das aus der Haupt-Table erzeugt wurde. Man würde dann kein Repository für die abhängigen Tables erzeugen.

Wir sind hier immer noch sehr abstrakt unterwegs, ich kann Dir darum keine konkreten Vorschläge für eine Implementierung machen. Angesichts des Projektumfangs könnte das auch zu weit führen.

Rolf

---

1. Ob Stub oder Mock oder Fake oder sonstwas - die Unittest-Päpste definieren sich da gerne den Wolf. Ich benutze in C# für sowas NSubstitute und die sagen dazu nur: We could ask for a stub, mock, fake, spy, test double etc., but why bother when we just want to substitute (...) ↩︎