SWARCH

• Repräsentiert db4o datenbanken
• stellt eine Transaktion dar, gestartet wenn container geöffnet
•  

Drei Abfrage Sprachen:

• Query by Example:
• Native Queries: In Programmiersprache selbst (typsicher!)
• Simple Object Data Access (SODA);

• Objekte müssen ohne initialisierte Felder kreiert werden können
• Man braucht einen Konstruktor um Objekte ohne initialisierte Felder zu erzeugen
• Man kann keine erweiterten Abfragen erstellen (AND,OR,NOT,...)
• Man kann keine default werte vergeben

• In der nativen Sprache (java)
• typensicher
• ändern sich beim Refactoren mit
• Vollkommen objektorientiert
• Können Methoden auf objekten in der DB ausführen

• Starten implizit wenn ein Container geöffnet wird
• Aktuelle Transaktion wird commited wenn Container geschlossen wird
• mann kann explizit commiten/aborten mit commit/rollback

z.B.http://www.tutorialspoint.com/design_pattern/data_access_object_pattern.htm

• Granularität (Beschaffenheit)
• Vererbung
• Identität
• Assoziationen
• Datennavigation

Objekte müssten auf relationale Tabellen abgebldet werden

Objecte werden auf relationen abgebildet. Beispiele hierfür sind z.B. Hybernate, Toplink, EBean, ...

Framework f+r die object relationale Abbildung. Hat keine eigene DB, braucht eine DB dahinter sowie Berechtigungen dafür.

Kann fast auf jedes RDBMS mappen. Vermittelt den eindruck ein OODBMS würde existieren.

Eine Schnittstelle für Java-Anwendungen, welche die Zuordnung und Übertragung von Objekten zu Datenbankeintragungen vereinfacht.

Metadaten definieren das Mapping von OO zu Relations (Mit Annotationen oder als XML)

Als XML file, heißt hybernate.cfg.xml und kommt in den src ordner des Projektes.

Konfiguriert den Typ der Datenbank (MySQL, PostgreSQL,Oracle,..), die Datenbank selber (User,

passwort, port), Einstellungen für Hibernate, Dateien oder Klassen die die Persistenz selber konfigurieren

• automatisch (Nützlich für nicht pre-existing DB)
• vom Entwickler (Nützlich für pre-existing DB)

• Serialisierbares Interface
• Konstruktor ohne Parameter
• getter/setter für alle persistenten Attribute (Bean)
• Attribut das als Primary Key dient (int id)

In einer Singelton HibernateUtil erzeugen wir eine sessionFactory:

(p19, Hibernate)

• Native SQL
  • SQL wie von der DB unterstüzt
• Hibernate Query Language (HQL)
  • wie SQL aber ohne OO navigation
  • bsp.: select <attribute> from <entity> where <properties>
• Criteria
  • fließendes Interface
  • um Abfragend dnyamisch zu bauen
• Am besten HQL für readability and Criteria für dynamic queries

• Reine abfrage, keine Updatesprache
• Versteht vererbung,polymorphie,object-orientierten besitz von Assoziationen
• Die miesten teiele sind optional

• Einfachste HQL-query: from Employee  (return all employees from db)
• Implementiert die vier ANSI join typen und Oracle-Cartesian-joins
• Clauses:
  • SELECT (optional)
  • FROM (required,except with Session.filter)
  • WHERE (optional)
  • Other: ORDER BY, GROUP BY, HAVING, ..
• Use createQuery("").list() um Query zu bauen

• API von Hibernate um Queries zu bauen (dynamisch)
• ähnlich wie Java
• bsp.: List<Book> books = session.createCriteria(Book.class).list();

• HQL ist nicht standartisiert, JPQL ist ein standartisierter Teil von HQL

• alternatives ORM in Java, default orm in play.
• EbeanServer:
  • EbeanServer s = Ebean.getServer(serverName);
• Ebean (singleton hat map zu Ebeanserver)
  • Customer customer = Ebean.find(Customer.class,4);
• unterstüzt fluent api

• Funktionale Anforderungen
• Nicht-funktionale Anforderungen
• Finanzielle Einschränkungen
• Erfahrung
• Verfügbare Technologie
• Bestehende Implementierungen
• Verfügbare Bibliotheken, Komponenten oder Frameworks

Selbe Applikation aber andere Hardware,feature set, user interface oder anderes backend.

--> Verschiedene Kunden,Preismodelle

Gleiche Applikation: Gleiche domain,Prozess,Interface,Technologie ABER unterschiedliche Datenmengen, unterschiedliche Abstraktionen.

• Versteht die gegebene Architektur (gegebenfalls)
• Analysiert Anforderungen,Einschränkungen für die nächste Phase der Entwicklung
• Wählt Sprache,Tool und Komponenten aus
• Entwickelt Zielarchitektur für die nächste Entwicklungsphase
• Verwaltet den Übergang
• Dokumentiert die Architektur

Viele Tems mit zwei zentralen Rollen organisiert: Dem Projektmanager und dem Softwarearchitekten. Kommunizieren viel miteinander. Andere Teammitglieder wären: Entwickler, Testentwickler, Deploymentspezialist, Perfomancespezialist, Dokumentierkerl

• Organisiert den Entwicklungsprozess
• überwacht den Fortschritt
• Passt auf Kosten auf
• Stellt Deadlines sicher
• Stellt Mitarbeiter ein
• Kommuniziert mit höherem Management
• Kommuniziert mit Kunden-Management

• Verantwortlich für technische Qualität des Codes/der Architektur
• Kommuniziert mit Kunden-domain-experten
• Versteht anforderungen/Limitierungen
• Kennt und bewertet viele Technologien um die passensten auszuwählen
• Gibt Domain - wissen an die Entwickler
• Berechnet Kosten
• Verteilt Aufgaben an Entwickler
• Kontrollt und hilft dem technischen Fortschritt der Aufgaben

Reenskaug ca 1970

Der Controller greift auf das Model zu, das Model auf die View.

Der Nachteil: Model hat Verbindung zur View, nimmt man das Model als Objektbaum ist die View mit drin! -> Viel zu groß wenn man es in die DB stecken mag

der Controller greift auf das Model zu, die View greift auch auf das Model zu. Die View ändert also direkt Daten

Nachteile: Wird das Model ausgetauscht kann das zu Problemen mit der View führen.

Server: Model,View,Controller         Client: -

Server: -     Client: Model,View,Contrller

-> Eigentliche Verarbeitung der Daten wird vor Ort auf Client vollzogen

Server: Model,           Client: Controller, View

-> Datenhaltung wo anders ( z.B. SAP)

Server: Model, Controller        Client: View

->Thin client: Stark auf andere Computer angewiesen

Server: Model, Controller               Client: Controller, View

--> Teil des Controllers auf Client, teil auf Server

Server: Model       Client: Model, View, Controller

-> Datenhaltungsschicht repliziert auf Server

Projekt nach Features gruppiert, pro Feature dann z.B. MVC.

Bsp.: Packages: com.app.doctor, com.app.drug, com.app.patient, com.app.security, ...

Projekt in Schichten aufgebaut (bsp. MVC) die die verschiedenen Features enthalten.

Object Database Management System