Opened by sid burn at 2009-02-01 17:39
User since
2003-08-04
12208 Artikel
Admin1
![[Homepage]](/battie/theme/default/homepage.gif)
2003-08-04
12208 Artikel
Admin1
sid burn+2009-02-01 16:39:04--Selbst das simple DBIx::Class Beispiel verstößt dort schon dagegen.
Code: (dl )$c->model('DB::User')->find({ user => $user });
Den in diesem Beispiel sagen wir ja schon das wir einen benutzer haben wollen
dessen "user" Spalte in der Datenbank $user ist. Sollte sich unser
Model ändern, z.B. entscheiden wir uns "username" im Model zu verwenden
dann sind alle Zugriffe im Controller kaputt. Eigentlich sollte uns
die Abstraktion als Model uns vor soetwas ja bewahren.
verstehe ich nicht. wenn du die spalte in der datenbank änderst, musst du noch lange nicht
den hashkey auch umbenennen. das definiert man ja alles im schema.
und jetzt sag mir mal, wo der unterschied ist (halb pseudo-code):
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
$dbic->find({ user => $user });
vs.
$dein_modell->find_user($user);
$dbic->find({ lastlogin => $date });
vs.
$dein_modell->find_lastlogin( $date);
$dbic->find($userid); # id ist PK
vs.
$dbic>find_id($userid);das schöne ist ja, dass du sowas ein einziges mal im schema definierst.
nach deinem modell müsste man fur jede spalte eine eigene methode schreiben.
wenn du gerne solche methoden schreibst, hält dich natürlich niemand davon ab,
aber ich bin da eher faul.
ausserdem kannst du im jeweiligen dbic-model auch eigene kurze zugriffsmethoden schreiben,
für oft gebrauchte felder z.b.
die grösste arbeit ist das schreiben des schemas, aber das ist für mich auch gleichzeitig
dokumentation und quelle für das erstellen/ändern der datenbank (mittels sqlt z.b.).
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen:
Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
lesen:
Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem