01 Persistence And Orm
0 likes595 views
The document discusses object-relational persistence and different approaches for managing persistent data in object-oriented applications, including ORM. It describes the paradigm mismatch between object-oriented programming and relational databases, specifically problems around granularity, subtypes, identity, associations, and object graph navigation. ORM is presented as a solution that transforms data between object and relational representations using metadata to govern this transformation.
01 Persistence And Orm
- 1. Object/Relational Persistence and ORM Persistent data in modern object-oriented applications & efficient data management
- 2. What is persistence? “Persistence” where data (state) outlives the process that created it In object-oriented applications: objects in a system are by default transient some of the objects in the graph are made persistent this subgraph of persistent instances can later be re-created in the same process or another process We need a data model and data store for persistent data... The Relational Data Model and SQL-based Database Management Systems.
- 3. What is persistence? PERSISTENCE APPROACHES 1. A well-know and widely used DAO design pattern to wide complex JDBC code and no portable SQL from business logic. ORM also uses DAO pattern 2. IBatis is a best persistence layer for legacy systems, Batch processing system and Report generation. JDBC, Spring-JDBC and IBatis(SQL Maps)
- 4. What is persistence? PERSISTENCE APPROACHES 3. EJB entity beans (CMP) Not fully object-oriented Doesn’t support polymorphic associations and queries Not portable across application servers Not fertilizable. Need to use DTO(Data transfer object or Value objects), and additional load Persistence runs only with EJB container Problems for Test Cases) In EJB3 no CMP, uses ORM for persistence Hibernate is good for JBOSS and major app. Servers Top Link is good for Oracle app. server
- 5. What is persistence? PERSISTENCE APPROACHES 4. Object-oriented database system (ODBMS) JDO (Java Data Objects) are popular. But, object-databases are not widely adopted. 5. XML Parses Advantages over Serialization but it is just another text file format.
- 6. What is persistence? PERSISTENCE APPROACHE 6. THE BEST FOR THE MOST PROBLEMS ORM (Object-Relation Model) An API for performing basic CRUD operations on objects of persistent classes A language or API for specifying queries that refer to classes and properties of classes A facility for specifying mapping metadata A technique for the ORM implementation to interact with transactional objects to perform dirty checking, lazy association fetching and other optimization functions.
- 7. What is persistence? PERSISTENCE APPROACHE 6. THE BEST FOR THE MOST PROBLEMS ORM (Object-Relation Model) ORM advantages: Productivity - no tedious SQL code Maintainability - Fewer lines of code makes the system more understandable Performance Vendor Independence
- 8. The persistence layer How does the Java application interact with the SQL database? Application layers group related code by concern prevent leakage of concerns have clear interfaces to avoid inter-layer dependencies A typical Layered Architecture and its interface dependencies: Persistence Layer Business Layer Presentation Layer Utility and Helper Classes
- 9. Tabular Data vs. Domain Model Some applications work exclusively with a tabular representation of persistent data: application works with tabular result sets in all layers straightforward with JDBC and SQL even better with detached RowSet (JSR 114) hard to code re-usable business logic Other applications have an object-oriented domain model : significant business logic, benefits from object-oriented techniques such as inheritance, polymorphism, and patterns greater degree of abstraction of the underlying relational data SQL / JDBC no longer so appropriate certain operations (batch processing, reporting) are more tabular in nature Some applications benefit from both , in different places.
- 10. Domain Model and the paradigm mismatch Classes implement the business entities of our domain model attributes of the entity are properties of our Java class associations between entities are also implemented with properties Let’s see if there is a problem mapping this to tables and columns... 1 1..* User userName: String address: String billingDetails: Set BillingDetails accountNumber: String accountName: String accountType: String user: User
- 11. Creating tables for the Domain Model SQL schema design for trivial cases is ... trivial: We’ll see the 5 problems of the O/R paradigm mismatch appear as we gradually make our model more complex… create table USER ( USER_NAME varchar not null primary key, ADDRESS varchar not null) create table BILLING_DETAILS ( ACCOUNT_NUMBER varchar not null primary key, ACCOUNT_NAME varchar not null, ACCOUNT_TYPE varchar not null, USER_NAME varchar foreign key references USER)
- 12. The problem of granularity should we create a new ADDRESS table? should we create a new SQL data type and change the column? user-defined data types (UDT) are not portable and the standard is weak We usually add new columns to USER with built-in SQL data types: create table USER ( USER_NAME varchar not null primary key, ADDRESS_STREET varchar not null, ADDRESS_CITY varchar not null, ADDRESS_ZIPCODE varchar not null ) User userName: String billingDetails: Set Address street: String city: String zipcode: String
- 13. The problem of subtypes We create subclasses of BillingDetails : and use polymorphism in Java to implement our billing strategy. How do we represent subtypes in our relational model? 1 1..* User BillingDetails CreditCard Cheque
- 14. The problem of identity In Java, we have two notions of "sameness" object identity is the memory location of an object, a==b object equality (what is this really?), a.equals(b) In SQL databases, we identify a particular row using the primary key and the table name. Often, this is a (meaningless) surrogate key ! What is the relationship between the three different types of identity in our domain model? Is the surrogate key propagated into the domain model?
- 15. The problem of associations Object-oriented languages represent entity relationships as object references (pointers) and collections of object references Relational databases represent entity relationships as copies of primary key values referential integrity ensured by foreign key constraints The mismatch: object references are directional, there is no such concept in the relational model many-to-many associations require a link table in relational databases
- 16. The problem of object graph navigation In Java, we "walk" the object graph by following references: david.getBillingDetails().getAccountName() In SQL, we join tables to get the required data: select * from USER u left outer join BILLING_DETAILS bd on bd.USER_ID = u.USER_ID where u.USERNAME = “david" Avoid the n+1 selects problem by minimizing the SQL required for graph walking!
- 17. The cost of the mismatch There problems can, at least theoretically, be solved using handwritten SQL/JDBC by writing a lot of tedious code (maybe 30% of your codebase) The “mismatch problem” is real better UDT support in SQL will not solve all the issues not all applications are suitable for table-oriented approaches Is the solution design patterns (DAO) or programming models (EJB entity beans)? "How should we implement the persistence layer in our application?"
- 18. Object/Relational Mapping Object / Relational Mapping (ORM) solve the mismatch problem in middleware an ORM solution transforms data from the object-oriented representation to the relational representation metadata governs this transformation Elements of an ORM implementation a programming model for the domain objects an API for performing CRUD operations a query language or other query facility a metadata facility