at-m42:lecture14
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
at-m42:lecture14 [2009/04/26 10:07] – eechris | at-m42:lecture14 [2009/04/26 10:10] – eechris | ||
---|---|---|---|
Line 584: | Line 584: | ||
* Better to use an existing framework. Many available! | * Better to use an existing framework. Many available! | ||
* 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 Persistence** for Java objects. | ||
+ | |||
---- | ---- | ||
Line 600: | Line 601: | ||
* 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 ===== | ||
+ | * // | ||
+ | * // | ||
+ | * " | ||
+ | * 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: | ||
+ | * Usually returned as a collection | ||
+ | * However objects in the collection should not be instantiated unless it is needed. | ||
+ | ===== Choosing a Persistence Strategy (1) ===== | ||
+ | * 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. | ||
+ | * 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 business logic changes, again, persistence code changes are limited to the access layer. | ||
+ | ===== Choosing a Persistence Strategy (2) ===== | ||
+ | * 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 // | ||
+ | * ORM is a complex strategy which be of benefit only for complex domain models and or databases | ||
+ | ===== Choosing a Persistence Strategy (3) ===== | ||
+ | ORM can be of benefit if: | ||
+ | * 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. | ||
+ | * A large number of objects exist but they are " | ||
+ | * There is a natural mapping between classes and fields and database tables and records | ||
+ | * 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! | ||
+ | | ||
+ | |||
+ | |||
+ | |||
===== 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 ===== | ||
* // | * // |
at-m42/lecture14.txt · Last modified: 2011/01/14 12:45 by 127.0.0.1