Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

NoSQL document oriented data access for .net systems with postgresql and marten

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio

Eche un vistazo a continuación

1 de 38 Anuncio

NoSQL document oriented data access for .net systems with postgresql and marten

Descargar para leer sin conexión

Relational-only databases are great fit for storing relational models, but are fairly problematic and limited when it comes to storing aggregates in DDD (domain-driven design) systems. On the other hand, NoSQL document-oriented databases are natural fit for storing and loading [DDD] aggregates.

In this session you are going to learn:
- Why relational-only databases are problematic and limited for storing aggregates and how document-oriented databases come into play.
- Why PostgreSQL is the perfect database for storing, loading and querying DDD aggregates.
- How Marten .NET library makes developers productive working with PostgreSQL's document features, leveraging the powerful JSONB data type, without losing any of your existing LINQ and SQL knowledge.
- And finally, how to use the features of both worlds combined (relational and document oriented) in the same database server, in order to get maximum out of this data access approach.

Overall, this approach helps dev teams be more productive and focus on designing good domain models, instead of fighting the impediment mismatch between the object model and the relational model, which comes from relational-only databases, with or without using an object-relational mapper. Ultimately, this approach opens the doors to polyglot persistence.

Relational-only databases are great fit for storing relational models, but are fairly problematic and limited when it comes to storing aggregates in DDD (domain-driven design) systems. On the other hand, NoSQL document-oriented databases are natural fit for storing and loading [DDD] aggregates.

In this session you are going to learn:
- Why relational-only databases are problematic and limited for storing aggregates and how document-oriented databases come into play.
- Why PostgreSQL is the perfect database for storing, loading and querying DDD aggregates.
- How Marten .NET library makes developers productive working with PostgreSQL's document features, leveraging the powerful JSONB data type, without losing any of your existing LINQ and SQL knowledge.
- And finally, how to use the features of both worlds combined (relational and document oriented) in the same database server, in order to get maximum out of this data access approach.

Overall, this approach helps dev teams be more productive and focus on designing good domain models, instead of fighting the impediment mismatch between the object model and the relational model, which comes from relational-only databases, with or without using an object-relational mapper. Ultimately, this approach opens the doors to polyglot persistence.

Anuncio
Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a NoSQL document oriented data access for .net systems with postgresql and marten (20)

Anuncio

Más reciente (20)

Anuncio

NoSQL document oriented data access for .net systems with postgresql and marten

  1. 1. Document-oriented data access for domain-driven .NET systems with PostgreSQL & Marten Bojan Veljanovski, CTO at HASELT October, 2017 @ Macedonian .NET User Group 1
  2. 2. What we are going to talk about? ● Limitations in relational-only DBs for storing true domain aggregates ● How document-oriented DBs come into play ● Marten as document DB for .NET with PostgreSQL ● SQL + NoSQL => best of both worlds 2
  3. 3. Setting context ● How I got interested in document-oriented DBs? Why it makes so much sense? ● Why PostgreSQL? Why not MongoDb, CouchDb, RavenDb? What about SQL Server, MySQL? ● Who else uses this approach? 3
  4. 4. Sample domain model 4
  5. 5. DDD Aggregate Cluster of domain objects that can be treated as a single unit. ● Consists of ○ Aggregate Root (or Root Entity) ○ Entities ○ Value Objects ○ Services ○ Repositories 5
  6. 6. Basic characteristics of an Aggregate Root ● Global identity ● Ensures invariants within aggregate ● Guarantees consistency ● Can reference other ARs only by identity ● Cannot reference non ARs ● Transactional consistency ● Stored and loaded in DB as a whole. 6
  7. 7. Relational-only model 7
  8. 8. Sample domain model in code Let’s see the sample codebase in Visual Studio. 8
  9. 9. Limitations when working with domain models in relational-only DBs... ● Cannot store an array of values ○ Needs new table with 1-m relation ● ...an array of objects ○ Needs new table with 1-m relation ● …a nested object ○ Needs new table with 1-1 relation ● …an AR in a single table ○ AR is spanned across many tables, and needs joinsThese limitations often lead to... 9
  10. 10. These limitations often lead to... ● Complex O/R mapping code ● Sacrificing encapsulation for easier O/R mapping ● Leak of domain logic to upper layers ● Anemic domain models - only data, no behavior ● Dev teams focusing on data-relations instead of system behavior ● Implicit “SELECT N+1” problems ● Unit tests full with mocks & stubs 10
  11. 11. Moving out of the relational-only mindset From thinking in terms of relations and data To thinking in terms of behavior and data 11
  12. 12. Document model 12
  13. 13. How document-oriented DBs come into play ● Single document per [whole] aggregate ● Can store complex object graphs ● Can store arrays, collections, nested objects ● No need for ORM ● No limitations for creating rich domain models ● Dev team focus is in on behavior and logic ● Models are easy to unit test 13
  14. 14. Introducing PostgreSQL 14
  15. 15. Introducing PostgreSQL ● Object-relational database ● ACID ● Transactional ● Highly Extendable ● Open Source ● Free 15
  16. 16. PostgreSQL NoSQL data types ● Key/Value store ○ hstore ● Document store ○ json and jsonb ● Spatial and Geographic objects ○ postgis 16
  17. 17. PostgreSQL as document store: Creating table with JSONB column 17
  18. 18. Inserting documents 18
  19. 19. Querying documents (1) 19
  20. 20. Querying documents (2) 20
  21. 21. Indexing documents Various indexes are supported. 21
  22. 22. Marten as Document DB for .NET with PostgreSQL 22
  23. 23. Introducing Marten ● OSS .NET library that provides polyglot persistence ● Document store ● Event store ● Uses PostgreSQL’s powerful JSON support ● Initial pre-alpha release on 08.12.2015 ● Current version 2.3.2 ● Community chat: gitter.im/JasperFx/marten 23
  24. 24. Getting started 24
  25. 25. Persisting documents 25
  26. 26. How our data looks like? -> User 26
  27. 27. Loading document by Id 27
  28. 28. Querying documents with LINQ 28
  29. 29. Filtering in arrays 29
  30. 30. Paging and sorting 30
  31. 31. Querying with plain SQL through Dapper (yes, querying NoSQL documents with plain-old SQL) 31
  32. 32. Adding Foreign Key to Order document 32
  33. 33. How our data looks like with FK? -> Order 33
  34. 34. Querying multiple documents by using SQL JOIN 34
  35. 35. Other notable features in Marten as Document Db ● Foreign Keys ● Indexes ● Duplicate columns ● Batched queries ● Compiled queries ● Bulk insert ● Multitenancy ● Optimistic Concurrency 35
  36. 36. Closing 36
  37. 37. Summary ● Relational-only DBs limit the ability to craft good domain models ● Document DBs are natural fit for DDD Aggregates ● SQL + NoSQL in Postgres = best of both worlds in a single DB provider ● Marten helps .NET devs leverage PostgreSQL as polyglot database ● Polyglot data access mindset - there is no single approach 37
  38. 38. Resources ● Marten ○ https://jasperfx.github.io/marten ○ https://gitter.im/JasperFx/marten ● PostgreSQL JSON Functions and Operators ○ https://www.postgresql.org ● This presentation’s code samples ○ https://github.com/bojanv91/MartenPostgreSamples ● Other useful articles ○ https://martinfowler.com/bliki/AggregateOrientedDatabase.html 38

×