Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

ORMs heróis ou vilões dentro da arquitetura de dados? - Otávio gonçalves

27 visualizaciones

Publicado el

Com a evolução dos aplicativos nascem novas técnicas, frameworks, linguagens de programação, porém, existe um fato consolidado dentro da arquitetura de software corporativo que é a integração com alguma tecnologia necessária para armazenar as informações inerentes ao sistema. Seja SQL ou NoSQL um ponto importante é que o paradigma das linguagens difere da tecnologia do banco de dados. Com o intuito de facilitar o desenvolvimento surgem as ferramentas que realizam a interpretação entre a camada da aplicação e os bancos. Assim, aparecem grandes desafios: como lidar com essa lacuna multiparadigma? Como favorecer o desenvolvimento sem impactar a performance e a modelagem no banco de dados? O objetivo dessa palestra é falar um pouco desses pontos para que, finalmente, os programadores e os DBAs conseguam viver em paz e harmonia.

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

ORMs heróis ou vilões dentro da arquitetura de dados? - Otávio gonçalves

  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

×