# design pattern: code in model classes



## H2SO3- (23. Jul 2011)

Hi,

hätte eine Frage wie man folgendes "Problem" löst indem man sich an ordendliche design pattern hält.

Model classes sind ja ansich sehr schön. Einfache Datencontainer ohne code. Sie sollen ja ansich keine eigene codelogic haben.


Was mache ich aber mit sehr einfachen code? zb. Ich habe eine Person in einer Firma. Diese Person ist idendifizierbar entweder durch eine id oder durch den namen. ich habe nun zwei constructoren


```
public Person(String name){...}

public Person(int id){...}
```

was ich nun an code brauche ist eine kleine DB abfrage jeweils nach dem namen oder nach der id. Je nachdem welcher constructor genommen wurde.

Wo packe ich nun am besten den Code rein? Direkt in eine private Methode des models oder in eine extra class?
Denke mal eine factory class ist ebenfalls falsch.


----------



## Noctarius (23. Jul 2011)

Für den Datenbankzugriff nutzt man DAOs.


----------



## H2SO3- (23. Jul 2011)

ist mir ansich zum teil schon wieder zu speziell.
Manchmal muss man auf ein wenige anderen code unterbringen. zb ob der name bestimmte bedingungen erfüllt usw. Spreche hier nicht von einem speziellen problem. Möchte eher allgemein wissen, wie man sowas löst.

Gibt es nicht was, was ein bishchen allgemeiner ist als ein DAO?

aber zum DAO. wie würde ich das eigentlich unterbingen im Pfad?

so:
mein.pfad.model
mein.pfad.model.dao

oder eher

mein.pfad.model
mein.pfad.dao
?

Das blöde bei beiden Lösungen ist halt, das ich alle methoden public halten muss obwohl ja eigentlich nur die classen in dem model package drauf zugriff haben sollen.


----------



## Noctarius (23. Jul 2011)

Ich würde die erste Variante nehmen. Das Problem mit öffentlich und so kann man später sehr schön mit dem zusätzlichen Access-Level Package von OSGi umsetzen.

Generell hat in den Datenklassen (TOs) mein Businesscode etwas verloren. Dafür sind entweder Service-Klassen oder DAOs zuständig.

Für Dinge wie "bestimmte Länge" oder "muss einem Regex entsprechen - z.B. E-Mail Adresse" würde ich den JSR303 (Bean Validation - z.B. mit Hibernate Validations) verwenden


----------



## H2SO3- (25. Jul 2011)

Hi,

habe mal nach "Access-Level Package von OSG" gegoogelt. Aber nicht wirklich was gefunden wo ich mir hierzu noch etwas durchlesen kann. Hast du vielleicht mal einen link?
Weiß nicht genau was du damit meinst.


----------



## Noctarius (25. Jul 2011)

Link müsste ich direkt auch suchen, aber kurz als Erklärung:

OSGi ist ein Modulsystem für Java. In OSGi teilst du deine App in möglichst sinnvolle, kleine Bruchstücke (die Bundles). Diese importieren oder exportieren Packages (die ganz normalen Packages aus deinem Programmcode).
Welche importiert oder exportiert werden kannst du explizit bestimmen und durch einen Classloader-Mechanismus kommst du von anderen Bundles auch nur an diese exportierten Packages dran.

Hier wurde sozusagen eine zusätzliche Access-Ebene zur Definition entwickelt, der Package-Level-Access.


----------

