DAO, getSession()

[MQue]

Hallo,

hätte noch eine konzeptionelle Frage, und zwar habe ich vom Buch Hibernate von Hennebrüder den Code unten, welcher eine Vorstufe zur generischen Variante ist.

Mir ist jetzt nicht ganz klar, für was ich DAOs benötige, wenn ich in der Methode unten dann eh wieder getSession() mit den DAOs mische,
Ich war bis jetzt der Meinung, dass ich mit den Sessions nicht mehr in berührung komme, wenn ich mich mit den DAOs eine Abstraktionsstufe höher begebe?

Liege ich da falsch?
lg

[B]protected void deliverPaperBook(Order order) {
		getSession().beginTransaction();
		OrderLineDao orderLineDao = DaoFactory.getOrderLineDao();
		ArticleDao articleDao = DaoFactory.getArticleDao();
		// create list of pdf to send and set status of orderline to delivered
		List orderLines = new ArrayList();
		boolean deliveredAll = true;
		for (Iterator iter = order.getOrderLines().iterator(); iter.hasNext();) {
			OrderLine element = (OrderLine) iter.next();
			orderLineDao.reattach(element);
			if (!element.getArticle().isEbook()) {
				if (!articleDao.lockAndDecrease(element.getArticle(), element
						.getQuantity())) {
					deliveredAll = false;
					break;
				}
				orderLines.add(element);
				orderLineDao.deliver(element);
			}
		}

		(new DeliverManager()).deliver(order.getCustomer(), orderLines);
		if (deliveredAll)
			getSession().getTransaction().commit();
		else {
			getSession().getTransaction().rollback();
			getSession().close();
		}

	}[/B]

 

[byte]

Du irrst Dich. DAOs sind keine Abstraktion über Hibernate. DAOs kapseln einfach den Hibernate Code!

Generic DAOs bieten einfach die Möglichkeit, die trivialen CRUD Methoden in einer Oberklasse zu implementieren, so dass man in den konkreten DAO-Klassen nur noch Entity-spezifische Methoden implementieren braucht (Prinzip: Dont Repeat yourself).

 

[MQue]

Du irrst Dich. DAOs sind keine Abstraktion über Hibernate. DAOs kapseln einfach den Hibernate Code!

Generic DAOs bieten einfach die Möglichkeit, die trivialen CRUD Methoden in einer Oberklasse zu implementieren, so dass man in den konkreten DAO-Klassen nur noch Entity-spezifische Methoden implementieren braucht (Prinzip: Dont Repeat yourself).

und was wir in der Methode gekappselt? man hat ja den Hibernate- Code wieder in der Methode (getSession().beginTransaction(); usw.) und dazu halt noch die DAOs!!??

 

[byte]

Beispiel:

Du hast ein Hibernate Objekt namens Employee mit den Feldern ID (Long) und Name (String). Dieses Objekt Employee hast Du mit Hibernate auf eine Tabelle in Deiner DB gemappt.

Nun möchtest Du in Deiner Anwendung Employees laden, ändern und speichern. Statt irgendwo im Code über die SessionFactory eine Session zu erzeugen und ein DB-Query abzufeuern, schreibst Du Dir ein DAO für Deine Klasse Employee.

Diese DAO Klasse könnte folgende Methoden definieren:

- public List<Employee> findAll()
- public Employee findById(Long id)
- public List<Employee> findByName(String name)
- public void save(Employee employee)

Um diese Methoden zu implementieren, musst Du eine SessionFactory haben, Dir eine Session holen, eine Transaktion öffnen, ein Query erzeugen, das Query abfeuern, die Transaktion commiten und das Resultat zurückgeben.

Die DAOs sind also gekoppelt an das verwendete Persistenz-Framework (Hibernate, TopLink, JPA, ...). Der Rest der Anwendung benutzt aber nur noch die DAOs, um mit der DB zu kommunizieren und muss vom Persistenz-Framework nichts wissen.

Das meine ich mit "DAOs kapseln den Hibernate-Code". Kapselung und Abstraktion ist nicht das gleiche!


Da es gewisse triviale DB-Methoden gibt, die für jede Entity gleich sind, bietet es sich an, diese Methoden in einer (generischen) Oberklasse zu definieren (einem Generic DAO). In obigem Beispiel könnte man die Methoden findAll, findById und save generisch implementieren.

Die Methode findByName hingegen kann man nicht generisch implementieren, weil das entsprechende DB-Statement eine Where-Clause enthält, die auf die Spalte des Namens geht. Diese Methode wäre also spezifisch für die Entität Employee und wäre somit die einzige Methode, die auch direkt im konkreten EmployeeDao implementiert werden.

 

[maki]

Mir ist jetzt nicht ganz klar, für was ich DAOs benötige, wenn ich in der Methode unten dann eh wieder getSession() mit den DAOs mische,

In dem Beispiel wird die Session nur aufgerufen, um Transaktionen zu steuern, dss ist so imho eh daneben mit Spring, wo man Transaktionen ganz einfach deklarativ per Annotation oder per XML konfiguriert, abgesehen davon sind Transaktionen imho etwas für die Applikations- bzw. Serviceschicht.

 

[-MacNuke-]

In dem Beispiel wird die Session nur aufgerufen, um Transaktionen zu steuern, dss ist so imho eh daneben mit Spring, wo man Transaktionen ganz einfach deklarativ per Annotation oder per XML konfiguriert, abgesehen davon sind Transaktionen imho etwas für die Applikations- bzw. Serviceschicht.

Gibt's dazu irgendwo ein Beispiel/Tutorial?

 

[byte]

Hier: Chapter9.Transaction management

 

[MQue]

In dem Beispiel sind Transaktionen imho etwas für die Applikations- bzw. Serviceschicht.

Was meinst du genau damit? Dass Transaktionen nichts in der Persistence- Schicht verloren haben sondern in der BussinessSchicht?

 

[maki]

Gibt's dazu irgendwo ein Beispiel/Tutorial?

Ja, in der Spring Doku Siehe Bytos link.
Am besten gleich zum Kapitel in dem Transaktionen durch Annotationen festgelegt werden.

Was meinst du genau damit? Dass Transaktionen nichts in der Persistence- Schicht verloren haben sondern in der BussinessSchicht?

Ja, denn genau da gehören sie hin.
Transaktionen sind Teil von Businessaufgaben, denn ein "primitives" Dao sollte wohl kaum wissen wann ein Use-Case aufhört und wann einer anfängt.

 

[byte]

Maki hat Recht. Eine DAO Methode führt idR ein SQL Statement aus. Transaktionen klammern aber idR mehrere SQL Statements.

Für gewöhnlich macht eine Business oder Service Methode die Transaktion auf. Dann kommen ein oder mehrere Aufrufe von DAO Methoden. Diese laufen alle in der selben Transaktion. Am Ende der Business Methode kommt dann das Commit.

Das lässt sich komfortabel deklarativ mit Spring konfigurieren. Einfach die Service- und DAO-Methoden mit @Transactional annotieren und die jeweils richtige Propagation setzen (DAO Methoden sollten eine Transaktion verlangen, jedoch keine selbst öffnen).

Details siehe Doku.