at-m42:lecture14
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
at-m42:lecture14 [2009/04/26 09:25] – eechris | at-m42:lecture14 [2011/01/14 12:45] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 389: | Line 389: | ||
===== … connect to database ===== | ===== … connect to database ===== | ||
<code java> | <code java> | ||
- | Connection c = DriverManager.getConnection(dbUrl, user, password); | + | Connection c = DriverManager.getConnection(DB, USER, PASSSWORD); |
</ | </ | ||
---- | ---- | ||
- | * Database | + | * The atabase |
* Connection object represents the database for rest of session. | * Connection object represents the database for rest of session. | ||
* Possible (and desirable) to pool connections if many clients may access same database simultaneously. | * Possible (and desirable) to pool connections if many clients may access same database simultaneously. | ||
Line 414: | Line 414: | ||
===== … execute query and return results ===== | ===== … execute query and return results ===== | ||
<code java> | <code java> | ||
- | ResultSet r = s | + | // SQL query |
- | .executeQuery(" | + | String QUERY = " |
- | + " | + | + " |
- | + " | + | + " |
- | + " | + | + " |
+ | // SQL code: | ||
+ | ResultSet r = s.executeQuery(QUERY); | ||
</ | </ | ||
Line 460: | Line 462: | ||
* If you have a pool of connections you'd want to release your connection (returning it to the pool) when you've finished. | * If you have a pool of connections you'd want to release your connection (returning it to the pool) when you've finished. | ||
| | ||
- | ====== Simplified Queries with Groovy ===== | + | ===== Simplified Queries with Groovy ===== |
+ | |||
<code groovy 1|Example 2; Database lookup in Groovy (at-m42/ | <code groovy 1|Example 2; Database lookup in Groovy (at-m42/ | ||
Line 472: | Line 475: | ||
In this example we note immediately that the opening of a connection to a database is achieved in a single //factory method// '' | In this example we note immediately that the opening of a connection to a database is achieved in a single //factory method// '' | ||
- | Further more, the use of multi-line strings simplifies the creation of queries, and because String interpretation works, queries can easily be made // | + | Further more, the use of multi-line strings simplifies the creation of queries, and because |
===== SQL Data-types and Java Data-types ===== | ===== SQL Data-types and Java Data-types ===== | ||
Line 534: | Line 537: | ||
===== Immortal Objects ===== | ===== Immortal Objects ===== | ||
- | * How to ensure that the state of your business objects survives (persists) beyond the ending of one process to the start of the next. E.g. to survive crashes and shutdown. | + | * How to ensure that the state of your business objects survives ('' |
* Although you can use files for persistence, | * Although you can use files for persistence, | ||
* These days you have to use a relational database. If you use Java to implement your application you have to use JDBC. | * These days you have to use a relational database. If you use Java to implement your application you have to use JDBC. | ||
* How can persistence issues can be affectively hidden from the business objects that rely on it? | * How can persistence issues can be affectively hidden from the business objects that rely on it? | ||
- | * Persistence is Last Step in a Transaction | + | ===== Persistence is Last Step in a Transaction |
* In distributed applications we need transactions to guarantee data integrity. | * In distributed applications we need transactions to guarantee data integrity. | ||
- | | + | |
* Transaction choreographs a persistence operation. | * Transaction choreographs a persistence operation. | ||
- | * When the transaction is notified that it is complete it creates a persistence transaction which tells each object modified in the transaction to insert, update or delete itself in the persistent store. | + | * When the transaction is notified that it is complete it creates a //persistence transaction// which tells **each object modified in the transaction** to //insert//, //update// or //delete// itself in the persistent store. |
- | * The persistence transaction makes sure that all data store accesses take place within a single data store transaction (i.e using the same connection object) and is committed at the end. | + | * The persistence transaction makes sure that all data store accesses take place within a **single data store transaction** (i.e using the same connection object) and is **committed** at the end. |
* The component model doesn' | * The component model doesn' | ||
- | | + | |
- | | + | ===== Component Transaction and Persistence Transaction |
+ | {{: | ||
===== Lecture Contents ===== | ===== Lecture Contents ===== | ||
- | | + | * [[#What is a Relational Database? |
* [[#The Trouble with Databases|JDBC -- Java database connectivity API]] | * [[#The Trouble with Databases|JDBC -- Java database connectivity API]] | ||
- | * [[Immortal Objects]] | + | * [[#Immortal Objects]] |
- | * [[Persistence Patterns]] | + | |
- | * [[Other forms of Enterprise Integration]] | + | * [[#Other forms of Enterprise Integration]] |
| | ||
- | ===== Persistence Patterns ===== | + | |
- | | + | ===== Persistence Patterns: Transaction script |
- | * This is known as the Transaction Script pattern: business logic is organized into procedures for each use case. | + | In many applications it is natural to work directly with the relational model, issuing SQL queries and parsing result sets. |
+ | * This is known as the // | ||
* Direct use of SQL is also well suited for aggregating queries and set-based updates (accessing large amounts of data or updating many tables in the same transaction) | * Direct use of SQL is also well suited for aggregating queries and set-based updates (accessing large amounts of data or updating many tables in the same transaction) | ||
- | * Another scenario is that you have simple queries returning small sets of rows (often in a single table), which receive selective updates. | + | |
+ | ===== Persistence Patterns: ORM ===== | ||
+ | |||
+ | Another scenario is that you have simple queries returning small sets of rows (often in a single table), which receive selective updates. | ||
* Little need for set-based updates | * Little need for set-based updates | ||
* Data entities mapped to persistent Java objects | * Data entities mapped to persistent Java objects | ||
* Business logic deals with these objects rather than the tables and records. | * Business logic deals with these objects rather than the tables and records. | ||
- | * General term for latter | + | General term for this pattern |
- | | + | |
- | | + | ===== Patterns for ORM Strategies |
- | * Active record – wraps a row in a database table, encapsulates the database access, and adds domain logic to the data. | + | * // |
- | * Data mapper – A layer of mappers that move data between objects and a database while keeping them independent of each other and the mapper itself. | + | * // |
- | * Query object – An object that represents a database query | + | * // |
- | * Unit of work – Maintains a list of objects effected by a business transaction and coordinates the writing of changes and the resolution of concurrency problems. | + | * // |
- | * | + | ===== Persistence Frameworks |
- | * Persistence Frameworks | + | |
- | * You can "roll your own” persistence framework | + | * You can "roll your own" |
- | * See e.g. extended examples in Reese. | + | |
- | * … but it’s a non-trivial task and fraught with difficulties and traps. | + | * ... but it's a non-trivial task and fraught with difficulties and traps. |
* Better to use an existing framework. Many available! | * Better to use an existing framework. Many available! | ||
- | * Most popular: CMP (more later), JDO (Java extension) | + | * All implement //Data Mapper//, //Query Object// and //Unit of Work// patterns to provide **Transparent Persistence** for Java objects. |
- | * All implement Data Mapper, Query Object and Unit of Work patterns to provide Transparent | + | |
- | | + | ---- |
+ | |||
+ | Reese (see [[Recommended Reading]]) gives an extended example of the development of a persistence framework. | ||
+ | |||
+ | The most widely used persistence frameworks are: | ||
+ | * Java EE Container Managed Persistence (CMP) (more later), | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * The " | ||
+ | |||
+ | ===== The Object/ | ||
* For all but the simplest domain models, there is no direct match from relational database to object model. | * For all but the simplest domain models, there is no direct match from relational database to object model. | ||
- | * OO concepts such as class, polymorphism, | + | * OO concepts such as class, |
- | * RDMS concepts such as normalized data, sets and efficient access have no direct relationship in the OO world. | + | * RDMS concepts such as //normalized data//, //sets// and //efficient access// have no direct relationship in the OO world. |
- | * It’s best to keep the two worlds separate and in the domain of the experts. | + | * It's best to keep the two worlds separate and in the domain of the experts. |
- | * Use an ORM framework (if it’s appropriate) to provide the bridge between the two worlds. | + | * Use an ORM framework (if it's appropriate) to provide the bridge between the two worlds. |
- | * | + | ===== Some Issues that the Developers of an ORM Have to be Aware Of ===== |
- | * Some Issues that the Developers of an ORM Have to be Aware Of | + | * //Identity//: ensuring a record in a database is unique in a global sense. |
- | * Identity: ensuring a record in a database is unique in a global sense. | + | * //Instantiated objects should be cached//: avoids a further trip to the database if it is needed in two separate transactions. |
- | * Instantiated objects should be cached: avoids a further trip to the database if it is needed in two separate transactions. | + | * "Dirty" |
- | * "Dirty” objects (objects that have been created or changed in a transaction) have to be committed to the database in a single atomic operation. | + | |
* Objects that have not been changed do not need to be written back to the database. | * Objects that have not been changed do not need to be written back to the database. | ||
* Queries may result in large numbers of records being returned from a database: | * Queries may result in large numbers of records being returned from a database: | ||
- | | + | |
- | * However objects in the collection should not be instantiated unless it is needed. | + | * However objects in the collection should not be instantiated unless it is needed. |
- | * | + | ===== Choosing a Persistence Strategy |
- | * | + | |
- | * | + | |
- | * | + | |
- | * Choosing a Persistence Strategy | + | |
* Many enterprise applications need to use legacy databases, or share the database with other systems, so choices are limited! | * Many enterprise applications need to use legacy databases, or share the database with other systems, so choices are limited! | ||
* Despite the hype, it is rare for an enterprise to change its database supplier, so it is often not worth completely abstracting the details of a DBMS out of code. | * Despite the hype, it is rare for an enterprise to change its database supplier, so it is often not worth completely abstracting the details of a DBMS out of code. | ||
- | * It is worth providing a data access layer so that your business logic does not talk directly JDBC but goes through a set of Data Access Objects. | + | * It is worth providing a data access layer so that your business logic does not talk directly JDBC but goes through a set of //Data Access Objects//. |
- | * If the database schema changes, it will be in the access layer that changes will be needed, not in the business logic. | + | * If the database schema changes, it will be in the access layer that changes will be needed, not in the business logic. |
- | * If the business logic changes, again, persistence code changes are limited to the access layer. | + | * If the business logic changes, again, persistence code changes are limited to the access layer. |
- | | + | ===== Choosing a Persistence Strategy |
- | * In some applications with a limited number of simple tables it will be quickest to use active record and talk directly to the database. | + | * In some applications with a limited number of simple tables it will be quickest to use //active record// and talk directly to the database. |
- | * If the application will require heavy use of set access, aggregation of data from many tables, or batch updates in many rows, a direct implementation using transaction script may be most efficient. | + | * If the application will require heavy use of set access, aggregation of data from many tables, or batch updates in many rows, a direct implementation using //transaction script// may be most efficient. |
* ORM is a complex strategy which be of benefit only for complex domain models and or databases | * ORM is a complex strategy which be of benefit only for complex domain models and or databases | ||
- | * Choosing a Persistence Strategy | + | ===== Choosing a Persistence Strategy |
- | | + | ORM can be of benefit if: |
* Your application has the typical CRUD – create, retrieve, update, delete – workflow for domain objects. | * Your application has the typical CRUD – create, retrieve, update, delete – workflow for domain objects. | ||
* Objects are found in large sets but are updated and deleted individually. | * Objects are found in large sets but are updated and deleted individually. | ||
- | * A large number of objects exist but they are " | + | * A large number of objects exist but they are " |
* There is a natural mapping between classes and fields and database tables and records | * There is a natural mapping between classes and fields and database tables and records | ||
- | * There are no unusual requirements such as the need to used customized SQL optimizations. | + | * There are no unusual requirements such as the need to use customized SQL optimizations. |
* For Java programmers ORM has the advantage of keeping SQL out of the code. But that is why we have DB architects! | * For Java programmers ORM has the advantage of keeping SQL out of the code. But that is why we have DB architects! | ||
| | ||
+ | |||
+ | |||
===== Lecture Contents ===== | ===== Lecture Contents ===== | ||
- | | + | * [[#What is a Relational Database? |
* [[#The Trouble with Databases|JDBC -- Java database connectivity API]] | * [[#The Trouble with Databases|JDBC -- Java database connectivity API]] | ||
- | * [[Immortal Objects]] | + | * [[#Immortal Objects]] |
- | * [[Persistence Patterns]] | + | * [[#Persistence Patterns]] |
- | * [[Other forms of Enterprise Integration]] | + | |
| | ||
===== Other Forms of Enterprise Integration ===== | ===== Other Forms of Enterprise Integration ===== | ||
* Enterprise integration is not just about databases and SQL. | * Enterprise integration is not just about databases and SQL. | ||
- | * Enterprise information systems | + | * Enterprise |
+ | * Main technologies for this form of integration is the Java Connectivity API and Web Services. | ||
+ | * May not be talking Java so CORBA and similar technologies may come into play. | ||
+ | |||
+ | ---- | ||
+ | |||
+ | Some examples of enterprise | ||
* Human Resources Systems | * Human Resources Systems | ||
* Payroll systems | * Payroll systems | ||
Line 633: | Line 656: | ||
* Business to Business Systems | * Business to Business Systems | ||
* Enterprise communication systems | * Enterprise communication systems | ||
- | * Other " | + | * Other // |
- | | + | |
- | * Main technologies are the Java Connectivity API and Web Services. | + | |
- | * May not be talking Java so CORBA and similar technologies come into play. | + | |
===== Lecture Summary ===== | ===== Lecture Summary ===== | ||
* [[#What is a Relational Database? | * [[#What is a Relational Database? | ||
* [[#The Trouble with Databases|JDBC -- Java database connectivity API]] | * [[#The Trouble with Databases|JDBC -- Java database connectivity API]] | ||
- | * [[Immortal Objects]] | + | * [[#Immortal Objects]] |
- | * [[Persistence Patterns]] | + | * [[#Persistence Patterns]] |
- | * [[Other forms of Enterprise Integration]] | + | * [[#Other forms of Enterprise Integration]] |
---- | ---- | ||
[[Home]] | [[lecture13|Previous Lecture]] | [[Lectures]] | [[lecture15|Next Lecture]] | [[Home]] | [[lecture13|Previous Lecture]] | [[Lectures]] | [[lecture15|Next Lecture]] |
at-m42/lecture14.txt · Last modified: 2011/01/14 12:45 by 127.0.0.1