01 persistence and domain modeling


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

01 persistence and domain modeling

  1. 1. Professional Open Source™ Persistence and Domain Modelling© JBoss, Inc. 2003, 2004. 07/17/04 1
  2. 2. The persistence layer Professional Open Source™  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: Presentation Layer Utility and Business Layer Helper Classes Persistence Layer© JBoss, Inc. 2003, 2004. 2
  3. 3. What is persistence? Professional Open Source™  “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.© JBoss, Inc. 2003, 2004. 3
  4. 4. PERSISTENCE APPROACHES Professional Open Source™  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© JBoss, Inc. 2003, 2004. 4
  5. 5. PERSISTENCE APPROACHES Professional Open Source™  2. EJB entity beans (CMP)  Not fully object-oriented   Doesn’t support polymorphic associations and queries   Not portable across application servers  Persistence runs only with EJB container  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© JBoss, Inc. 2003, 2004. 5
  6. 6. PERSISTENCE APPROACHES Professional Open Source™  3. Object-oriented database system (ODBMS)  JDO (Java Data Objects) are popular.  But, object-databases are not widely adopted.© JBoss, Inc. 2003, 2004. 6
  7. 7. PERSISTENCE APPROACH Professional Open Source™ 4. 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.© JBoss, Inc. 2003, 2004. 7
  8. 8. PERSISTENCE APPROACH Professional Open Source™ 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© JBoss, Inc. 2003, 2004. 8
  9. 9. Analyzing the business domain Professional Open Source™  A software development effort begins with analysis of the problem domain  At this stage, you, with the help of problem domain experts, identify the main  entities that are relevant to the software system. Entities are usually notions  understood by users of the system: payment, customer, order, item, bid, and so  forth.  All these entities are found in the conceptual view of the business, which we sometimes call a business model.  Developers and architects of object-oriented software analyze the business model and create an object-oriented model, still at the conceptual level (no Java code). This model may be as simple as a mental image existing only in the mind of the developer, or it may be as elaborate as a UML class diagram© JBoss, Inc. 2003, 2004. 9
  10. 10. What is Domain model ? Professional Open Source™  Object Oriented model contains entities that you’re bound to find in any typical system: category, item, and user. The entities and their relationships (and perhaps their attributes) are all represented by this model of the problem domain.  We call this kind of object-oriented model of entities from the problem domain, encompassing only those entities that are of interest to the user, a domain model. It’s an abstract view of the real world.  The domain model is a rich object model, with complex associations,  interactions, and inheritance relationships© JBoss, Inc. 2003, 2004. 10
  11. 11. Persistence classes of a domain model and their relationships Professional Open Source™© JBoss, Inc. 2003, 2004. 11
  12. 12. Implementing the domain model Professional Open Source™  An issue that any implementation will deal with is Separation of concerns  The domain model implementation is usually a central, organizing  component; it’s reused heavily whenever you implement new application functionality.  So, u have to ensure that concerns other than business aspects don’t leak into the domain model implementation.© JBoss, Inc. 2003, 2004. 12
  13. 13. Addressing leakage of concerns Professional Open Source™  The domain model implementation is such an important piece of code that it shouldn’t depend on orthogonal Java APIs. For example, code in the domain model shouldn’t perform JNDI lookups or call the database via the JDBC API. This allows you to reuse the domain model implementation virtually anywhere.  Domain model should be concerned only with modeling the  business domain. However, there are other concerns, such as persistence, transaction management, and authorization. You shouldn’t put code that addresses these crosscutting concerns in the classes that implement the domain model. When these concerns start to appear in the domain model classes, this is an example of  leakage of concerns.  Hibernate is a solution for just one of these concerns: persistence© JBoss, Inc. 2003, 2004. 13
  14. 14. Transparent and automated persistence Professional Open Source™  We use transparent to mean a complete separation of concerns between the persistent classes of the domain model and the persistence logic, where the persistent classes are unaware of—and have no dependency on—the persistence mechanism  The Item class, for example, doesn’t have any code-level dependency on any Hibernate API. Furthermore: – Hibernate doesn’t require that any special super classes or interfaces be inherited or implemented by persistent classes. – Persistent classes can be reused outside the context of persistence, in unit tests or in the user interface (UI) tier, for example. – In a system with transparent persistence, objects aren’t aware of the underlying data store; they need not even be aware that they are being persisted or retrieved. Persistence concerns are externalized to a generic persistence manager interface—in the case of Hibernate, the Session and Query© JBoss, Inc. 2003, 2004. 14
  15. 15. Domain Model and the paradigm mismatch Professional Open Source™  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 BillingDetails User accountNumber: String userName: String 1 1..* accountName: String address: String accountType: String billingDetails: Set user: User Let’s see if there is a problem mapping this to tables and columns...© JBoss, Inc. 2003, 2004. 15
  16. 16. Creating tables for the Domain Model Professional Open Source™  SQL schema design for trivial cases is ... trivial: 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) We’ll see the 5 problems of the O/R paradigm mismatch appear as we gradually make our model more complex…© JBoss, Inc. 2003, 2004. 16
  17. 17. The problem of granularity Professional Open Source™ Address User street: String userName: String city: String billingDetails: Set zipcode: String – 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)© JBoss, Inc. 2003, 2004. 17
  18. 18. The problem of subtypes Professional Open Source™  We create subclasses of BillingDetails: 1 1..* User BillingDetails CreditCard Cheque  and use polymorphism in Java to implement our billing strategy.  How do we represent subtypes in our relational model?© JBoss, Inc. 2003, 2004. 18
  19. 19. The problem of identity Professional Open Source™  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?© JBoss, Inc. 2003, 2004. 19
  20. 20. The problem of associations Professional Open Source™  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© JBoss, Inc. 2003, 2004. 20
  21. 21. The problem of object graph navigation Professional Open Source™  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!© JBoss, Inc. 2003, 2004. 21
  22. 22. The cost of the mismatch Professional Open Source™  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?"© JBoss, Inc. 2003, 2004. 22
  23. 23. Object/Relational Mapping Professional Open Source™  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© JBoss, Inc. 2003, 2004. 23
  24. 24. Implementing POJO associations Professional Open Source™  You use properties to express associations between POJO  classes, and you use accessor methods to navigate from  object to object at runtime.  Let’s consider the associations defined by  the Category class, as shown in the figure: This is what the scaffolding code for the one-to-many self- association of Category looks like: public class Category { private String name; private Category parentCategory; private Set childCategories = new HashSet(); public Category() { } ... }© JBoss, Inc. 2003, 2004. 24
  25. 25. Implementing POJO associations Professional Open Source™  To allow bidirectional navigation of the association, you require two attributes. The parentCategory field implements the single-valued end of the association and is declared to be of type Category. The many- valued end, implemented by the childCategories field, must be of collection type. You choose a Set, because duplicates are disallowed, and initialize the instance variable to a new instance of HashSet.  Hibernate requires interfaces for collection-typed attributes, so you must use java.util.Set or java.util.List rather than HashSet, for example.  The basic procedure for adding a child Category to a parent Category looks like this: – Category aParent = new Category(); – Category aChild = new Category(); – aChild.setParentCategory(aParent); – aParent.getChildCategories().add(aChild);© JBoss, Inc. 2003, 2004. 25
  26. 26. Implementing POJO Associations Professional Open Source™  Whenever a link is created between a parent Category and a child Category, two actions are required: – The parentCategory of the child must be set, effectively breaking the association between the child and its old parent (there can only be one parent for any child). – The child must be added to the childCategories collection of the new parent Category.  It’s a good idea to add a convenience method to the Category class that groups these operations, allowing reuse and helping ensure correctness, and in the end guarantee data integrity:© JBoss, Inc. 2003, 2004. 26
  27. 27. Adding logic to accessor methods Professional Open Source™  For example, if your database stores the name of a user as a single NAME column, but your User class has firstname and lastname properties, you can add the following persistent name property to the class:© JBoss, Inc. 2003, 2004. 27
  28. 28. Performing validation in Accessor Method Professional Open Source™  Accessor methods can also perform validation. For instance, in the following example, the setFirstName() method verifies that the name is capitalized:© JBoss, Inc. 2003, 2004. 28
  29. 29. Dirty Checking issue Professional Open Source™  Hibernate automatically detects object state changes in order to synchronize the updated state with the database. It’s usually safe to return a different object from the getter method than the object passed by Hibernate to the setter. Hibernate compares the objects by  value—not by object identity—to determine whether the property’s persistent state needs to be updated. For example, the following getter method doesn’t result in unnecessary SQL UPDATEs: – public String getFirstname() { – return new String(firstname); – }  There is one important exception to this: Collections are compared by identity!  For a property mapped as a persistent collection, you should return exactly the same collection instance from the getter method that Hibernate passed to the setter method. If you don’t, Hibernate will update the database, even if no update is necessary, every time the state held in memory is synchronized with the database.© JBoss, Inc. 2003, 2004. 29