O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

ORMs: Heroes or Villains Inside the Architecture?

51 visualizações

Publicada em

In the information age, with new technologies, frameworks, and programming languages, there is an aspect of technology that never changes. All applications need a storage integration related to their system; either SQL or NoSQL, to point out that there is a different paradigm among the development team and the database team. To make developer life easier, new frameworks emerged that convert between the application layer and the database, which includes the famous ORM. Indeed, contemporary challenges appear such as how to handle different paradigms that are in software development and how to make a regular development without impacting on the database.

Publicada em: Tecnologia
  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto

ORMs: Heroes or Villains Inside the Architecture?

  1. 1. Otávio Santana @otaviojava ORMs heroes or villains indoors the data architecture?
  2. 2. Architecture vs Design ● Flexibility ● Scalability ● Reusability ● Module is doing ● The classes scope ● The functions purposes
  3. 3. Architecture ● Serverless Architecture ● Event-Driven Architecture ● Microservices Architecture
  4. 4. Design ● Single Responsibility Principle ● Open Closed Principle ● Liskov substitution principle ● Interface Segregation Principle ● Dependency Inversion Principle ● Design Patterns
  5. 5. Divide and Conquer
  6. 6. Modules ● Hardware History ● Testability ● Mock
  7. 7. Layer vs Tier
  8. 8. Layers Data Access Layer DAO API
  9. 9. Paradigms ● Objects ● Functional ● Reactive ● Relational ● Key-value ● Column-Family ● Document ● Graph
  10. 10. Conversion
  11. 11. Mapper Real entities Less Database Less boilerplate More domain visibility in your system
  12. 12. Mapper Real entities are not database structure Less Database means bad database design Less boilerplate is not magic Domain is not Database
  13. 13. Active Record ● Simple ● Easy to learn public class Person extends Model {} Person person = new Person("Ada","Lovelace"); person.saveIt(); Person ada = Person.findFirst("name = ?", "Ada"); String name = ada.get("name"); ada.delete(); List<Person> people = Person.where("name = 'Ada'");
  14. 14. Active Record ● Database Coupling ● Performance bottlenecks ● Transactions? ● Connections? ● Pool?
  15. 15. Mapper @Entity public class Person { private @Id String name; private @Column String lastName; } EntityManager manager = getEntityManager(); manager.getTransaction().begin(); Person person = new Person("Ada","Lovelace"); manager.persist(person); manager.getTransaction().commit(); List<Person> people = manager.createQuery("SELECT p from Person where p.name = @name").setParameter("name", "Ada").getResultList(); ● Flexibility ● Performant
  16. 16. Mapper ● Hard ● Setup
  17. 17. Object-relational impedance mismatch ● Encapsulation ● Accessibility ● Interface, class, inheritance and polymorphism ● Data type differences
  18. 18. Model ● Database normalization ● Database denormalization
  19. 19. Keys The AUTOINCREMENT keyword imposes extra CPU, memory, disk space, and disk I/O overhead and should be avoided if not strictly needed. It is usually not needed. ● Performance ● Security ● Compound key ● UUID?
  20. 20. Performance issues ● Indexes ● N+1 Query ● Search Engine
  21. 21. Cache
  22. 22. Security Hard coding Plain password One user
  23. 23. Schemaless ● Data integrity ● Security ● Validation
  24. 24. Rich Model ● Smart Domain Objects ● Thin Services ● Encapsulate ● No Procedural code
  25. 25. Designing Bulletproof Code ● Hide data ● Expose behavior ● Don't memorize ● Consistency in the Model
  26. 26. Designing Bulletproof Code ● Builder ● Fluent API ● DSL ● Factory Method ● When Make a Type
  27. 27. Clean Architecture ● Split what matter ● Domain Layer does NOT depend on Data Layer. ● Agnostic
  28. 28. Database Adapter Layer
  29. 29. Silver Bullet
  30. 30. Summary ● Impact ● Volumetry ● Active Record vs Object Mapper ● Design outside the code ● Know-how vs Know-why ● Index ● Model to Data ● Trade-offs ● DBA is not your enemy
  31. 31. Thank you Otavio Santana @otaviojava

×