Чурюканов Вячеслав, “Code simple, but not simpler”
Download as PPTX, PDF1 like464 views
Code simple, but not simpler discusses ways to develop enterprise applications based on "POJOs in Action" by Chris Richardson. Key messages include making everything as simple as possible while avoiding oversimplification, and that every technology has benefits and drawbacks. The document discusses domain models, transaction scripts, encapsulating business logic, accessing databases, handling concurrency, and long transactions. It compares object-relational mapping frameworks to other data access approaches and concurrency patterns like optimistic and pessimistic locking.
Ad
More Related Content
Viewers also liked (20)
Similar to Чурюканов Вячеслав, “Code simple, but not simpler” (20)
Ad
More from EPAM Systems (20)
Ad
Чурюканов Вячеслав, “Code simple, but not simpler”
- 1. Code simple, but not simpler Discuss ways to develop enterprise applications based on “POJOs in Action” by Chris Richardson
- 2. Who am I? Viachaslau Churukanau Senior Software Engineer, Java world Edmunds.com, room 404
- 3. INTRODUCTION
- 4. You have to design enterprise applications at some moment But how to develop this skill if: • There are no appropriate trainings • The Internet usually provides little, contradictory and out of date knowledge • People tell you “lie” • Etc. ?
- 5. Correct Solution Read Books and Try
- 7. POJOs in Action (2006) • shows how to address many common and complex design issues in back-end logic development of enterprise applications with fantastic real-world examples • combines best practices and design wisdom to integrate domain-driven design and test-driven development for object-oriented applications • carefully explains the techniques and technologies used at various levels, including Spring, JDO, Hibernate, EJB 3, and iBatis.
- 8. Key Messages • Regardless of how the frameworks evolve, there are some key concepts that will not change • Every technology has both benefits and drawbacks • Make everything as simple as possible, but not simpler (Albert Einstein)
- 10. ORGANIZING THE BUSINESS LOGIC
- 13. Benefits and Drawbacks + Improved maintainability and extensibility + Persistence framework enables you to easily map the domain model to the database - You should have good OOD skills
- 15. Benefits and Drawbacks + Easy to Use (no OOD skill required) + Can use full range of SQL features - Code can be difficult to understand and maintain (complex business logic, explicit load and save all required data) - Cost of maintaining handwritten SQL (e.g. add a column – change multiple queries) - Lack of portability of SQL
- 16. When to Use • The application must use SQL directly or you cannot use a persistence framework • The business logic is very simple • The development team lacks the necessary OO design skills
- 18. EJB session / POJO facade
- 19. Benefits and Drawbacks + Business Logic is encapsulated and is free of transaction management (including distributed transactions), security, remote access, detaching objects, etc. - You must write extra code - It is quite easy for the detachment code and the presentation tier to get out of sync and for the POJO façade to only return some of the objects required by the presentation tier
- 20. Exposed Domain Model (Open Session in View)
- 21. Benefits and Drawbacks + Faster development (the business tier does not contain façades or error-prone detachment logic) - Less encapsulation (it is quite easy for business logic to creep into the presentation tier; the presentation tier has access to the domain objects; business tier changes affect presentation tier) - No support for remote access - Tricky to configure interactions between transactions, persistence framework, and the servlet API
- 23. What’s wrong with using JDBC directly • Developing and maintaining SQL is difficult and time consuming • There is a lack of portability with SQL • Writing JDBC code is time consuming and error-prone
- 24. What if I need SQL? • You must use the full power of SQL, including vendor-specific features, in order to get good performance • Your DBA might demand complete control over the SQL statements executed by your application • The corporate investment in its relational databases is so massive that the applications working with the databases can appear relatively unimportant
- 25. iBatis • Insulates the application from connections and prepared statements, iBATIS maps JavaBeans to SQL statements using XML descriptor files or annotations • Supports for database-generated primary keys, automatic loading of related objects, caching, and lazy loading
- 26. Why you don’t want to persist objects yourself 1. Lazy Loading (loading all of the objects that might be accessed might be extremely inefficient) 2. Writing back to the database only those objects that have been modified (it would be extremely inefficient to save all objects regardless of whether they have changed) 3. The database access code must preserve object identity by ensuring that there is a single in- memory instance of a persistent object when processing a request
- 28. Кey features of an ORM framework • Declarative mapping between the object model and database schema • An API for creating, reading, updating, and deleting objects • A query language • Support for transactions • Lazy and eager loading • Caching • Detached objects
- 29. Benefits and Drawbacks + Improved productivity + Improved performance + Improved portability +- Sometimes you must use SQL directly (performance, etc.) - Challenging when you’re working with a legacy schema (e.g. denormalized) - You might design a domain model that cannot be mapped to the desired database schema
- 30. HANDLING CONCURRENCY IN DATABASE TRANSACTIONS
- 31. Read Phenomena
- 32. Isolated Database Transactions • The database ensures that the outcome of executing multiple serializable transactions is the same as executing them serially. • Serializable transactions prevent such problems as lost updates and inconsistent reads
- 33. Benefits and Drawbacks + They are simple to use + They prevent many concurrency problems, including lost updates and inconsistent reads - They produce the high overhead, which can reduce performance and scalability - Fully isolated transactions can fail more frequently than less isolated transactions because of deadlocks and other concurrency- related issues
- 34. When to Use • Read consistency is essential • The overhead of fully isolated transactions is acceptable
- 36. Benefits and drawbacks + Unlike optimistic locking, pessimistic locking does not require any schema changes + It prevents a transaction from overwriting another transaction’s changes + It reduces the probability of deadlocks in databases that implement fully isolated transactions by locking rows when they read - All potentially conflicting transactions have to use SELECT FOR UPDATE in order for pessimistic locking to work, which is potentially error-prone - Some databases have limitations on how SELECT FOR UPDATE can be used
- 37. When to Use • The database schema does not support optimistic locking because, for example, the tables do not have a version or timestamp column or contain values such as floats or blobs that cannot be compared • The application requires some degree of read consistency • You don’t want to incur the overhead of serializable transactions
- 39. Benefits and Drawbacks + It is easy to implement and it is supported by many persistence frameworks + Unlike pessimistic locking, does not prevent an application from using certain SQL SELECT statement features - All potentially conflicting transactions must use optimistic locking or errors will occur - No guarantee that a transaction will be able to update the rows that it read - Does not prevent inconsistent reads
- 40. When to Use General recommendation is that an application should use optimistic locking unless: • The database schema does not support optimistic locking • The application must be guaranteed to be able to update the rows that it read • The application requires consistent reads
- 41. HANDLING CONCURRENCY IN LONG TRANSACTIONS
- 43. What’s wrong with using a single database transaction • The database transaction would be long- running because it encompasses multiple web requests and user think time • The transaction might last until the web session timed out if the user could simply walk away from the browser without completing the use case • It reduce scalability and concurrency
- 45. Benefits and Drawbacks + Ensures that a user can save changes - Impacts the application globally (don’t forget to use it in a new code, etc.) - Requires a mechanism to forcibly release locks
- 46. When to Use • The probability of conflicts is high • The consequences of conflicts are severe • Users typically do not abandon their sessions or it’s feasible to implement a lock cleanup mechanism
- 48. Benefits and Drawbacks + It is relatively easy to implement + Unlike the Pessimistic Offline Lock pattern, there are no locks to clean up if the user abandons the session, which is not uncommon in a web application. - Because the Optimistic Offline Lock pattern only detects changes when the user tries to save their changes, it only works well when starting over is not a burden on the user - All transactions that update shared data must increment the version number whenever they update a row, including those that do not use the Optimistic Offline Lock pattern
- 49. When to Use • The probability of conflicts is low and the consequences of redoing the changes are minimal • Users regularly abandon sessions and you don’t want to implement a lock cleanup mechanism
- 50. Summary
Editor's Notes
- #21: No problems with detached objects.
- #36: This mechanism assumes that concurrent updates will occur and so incurs an overhead regardless of whether they do.
- #39: Optimistic locking derives its name from the fact it assumes that concurrent updates are rare and that instead of preventing them the application detects and recovers from them.