Benennung von Methoden mit DB-Zugriff

HoPi

Mitglied
Moin Jungs (und Mädels),

ich mache mir gerade über sinnvolle Benennung meiner Methoden Gedanken. Ich kenne ein paar Richtlinien, an die man sich halten soll (möglichst kurz aber noch aussagekräftig, CamelCase, ...), aber scheitere an einem eigentlich simplen Problem: die Namen von Methoden, die aus einer Datenbank lesen.

Die möglichen Szenarien:
1) Lesen von allen Datensätzen
a) ohne Filter
b) mit Filter (where...)
2) Lesen eines Datensatzes (mit Filter, häufig nach ID)

Ich habe einige Zeit mit Namen wie getCustomers und getCustomer gearbeitet, was ja für sich selbst spricht. getCustomers hatte dann einen optionalen Parameter für den Filter. Einige Methoden, die ich übernommen hatte, hatten deutsche Bezeichnungen, z.B. getMitarbeiter. Um alle auszulesen, wurde mal getMitarbeiters, mal getAllMitarbeiter genutzt - das hat mich zwar gestört, aber man gewöhnt sich an alles :) da die Datenbank-Tabellen auch zum Teil deutsche Namen hatten, war das sogar halbwegs sinnvoll.

Was macht ihr in so einem Fall?
 
Hallo,

Da es hier letzendlich um ein Benennungsproblem mit zahlreichen Lösungen handelt kann man sich hierüber natürlich streiten ;-)

Eine Möglichkeit für einfache DAOs / Repositories (http://www.manning-sandbox.com/message.jspa?messageID=51472) wäre Beispielsweise:
BubuRepository
getBy(id) / getBubuBy(id) -> liefert bubu mit der id id oder null wenn nicht existent.
findAll() / findBubus() -> liefert alle Bubus
findBy(query) -> liefert alle bubus die den einschränkungen in der query genügen.
findByXXX(xxx) -> liefert alle bubus deren XXX eigenschaft auf xxx steht

Allgemein:
get liefert eine oder keine Instanz zurück.
find liefert mehrere oder keine Instanz zurück

save(bubu) // saveOrUpdate / merge speichern
//update(bubu) merge
delete(bubu) //löschen

Gruß Tom
 
Ich kann Tom nur beipflichten. IMHO ist es egal für welches Namenssystem du dich entscheidest solang du das Schema konsistent verwendest. Will heißen entweder readBy oder findBy.

Ansonsten macht es halt Sinn, Persistenzoperationen in eigenen Interfaces/Klasse auszulagern um so eine sinnvolle Gruppierung zu erreichen.

Gruß
Ollie
 

Neue Beiträge

Zurück