Downloaded 72 times
Uploaded byIgor Anishchenko
Spring Data - Intro (Odessa Java TechTalks)
The document provides an overview of Spring Data, focusing on its integration with NoSQL and relational databases such as MongoDB, emphasizing its flexible data model and ease of scalability. It discusses components like JPA for object/relational mapping, repository abstractions, and the use of templates for simplified data access. Finally, it highlights the Spring Data mission statement and the importance of a consistent programming model while retaining specific features of different data stores.
More Related Content
Similar to Spring Data - Intro (Odessa Java TechTalks)
Spring Data - Intro (Odessa Java TechTalks)
- 1. Spring Data Igor Anishchenko Lohika - September, 2012
- 2.
- 3.
- 4.
- 6.
- 7.
- 8.
- 9.
- 10. MongoDB Document Database JSONdocuments JSON queries
- 11. MongoDB The most importantdifference is the data model:
- 12. Mongo data model AMongo system (see deployment above) holds a set of databases A database holds a set of collections A collection holds a set of documents A document is a set of fields A field is a key-value pair A key is a name (string) A value is a basic type like string, integer, float, timestamp, binary, etc., a document, or an array of values
- 13. MongoDB • Flexible datamodel • Data can be inserted without a defined schema, and the format of the data being inserted can change at any time • Easy scalability • Databases automatically spreads data across servers, requiring no participation from the applications. • Servers can be added and removed without downtime
- 14.
- 15.
- 16.
- 17. " This documentis the specification of the Java API for the management of persistence and object/relational mapping with Java EE and Java SE. The technical objective of this work is to provide an object/relational mapping facility for the Java application developer using a Java domain model to man- age a relational database.
- 18. " This documentis the specification of the Java API for the management of persistence and object/relational mapping with Java EE and Java SE. The technical objective of this work is to provide an object/relational mapping facility for the Java application developer using a Java domain model to man- age a relational database.
- 19.
- 20. Decision Time? As a developer - what are you looking for?
- 21.
- 22. Mission statement “… providesa familiar and consistent Spring-based programming model for NoSQL and relational stores while retaining store-specific features and capabilities”
- 23. ... history • TheSpring Data project was coined at 2010 • Originated by Rod Johnson (SpringSource) and Neo Technologies) early that year • They were trying to integrate the Neo4j graph database with the Spring framework and evaluated different approaches • Current version
- 24. Spring Data JDBC JPA support for relational stores...
- 25. Spring Data JDBC JPA support for relational stores...
- 26. Spring Data JDBC JPA support for relational stores...
- 27. Spring Data JDBC JPA support for relational stores...
- 28. Spring Data JDBC JPA support for relational stores...
- 29. Core components Building blocksof Spring Data modules
- 30. Spring Core • IoC/DI • Spring namespace • Configuring resources to access the stores • Integration with core Spring functionality like JMX is provided which means that some stores will expose statistics through their native API
- 31.
- 32. ...Mapping • A verycore part of the Spring Data modules is a mapping and conversion API that allows obtaining meta-data about domain classes • Most of the NoSQL Java APIs do not provide support to map domain objects onto the stores data abstractions • With native Java drivers You would usually have to write a significant amount of code to map data onto your domain objects
- 33.
- 34. Entity mapping -MongoDB
- 35.
- 36. ... Templates • Heavilyused in spring (JdbcTemplate, JmsTemplate) • JdbcTemplate - simplifies the use of JDBC and helps to: • avoid common errors • executes core JDBC workflow • SQL queries or updates, iteration over ResultSets and • catching JDBC exceptions • Spring takes this concept and provided templates for noSQL stores • RedisTemplate • MongoTemplate • Offer helper methods that allow us to execute commonly needed operations like persisting an object with a single statement while automatically taking care of appropriate resource management and exception translation
- 37.
- 38.
- 39.
- 40.
- 41. ... Repositories • Providesa repository abstraction on top of the Template implementation • Will reduce the effort to implement data access objects to a plain interface definition for the most common scenarios like standard CRUD operations as well as executing queries in case the store supports that. • This abstraction is actually the most top layer and blends the APIs of the different stores as much as reasonably possible. • Interface based programming model, so you have an interface for the queries you want to trigger and then those methods will be generated without a need to implement this interface
- 42.
- 43.
- 44.
- 45.
- 46. Summary • Abstraction over stores drivers • Mapping support • Templates • Repositories / custom repositories • Querydsl • Spring namespace • Cross-store persistence
- 47. ? ? ? ? ? ?
- 48. Resources www.springframework.org/spring-data http://github.com/SpringSource/spring-data-mongodb O'Reilly's Open FeedbackPublishing System is the book: http://ofps.oreilly.com/titles/9781449323950/ http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
Editor's Notes
- #5 Scaling is the problem - http://prabhubuzz.wordpress.com/2010/09/06/not-only-sql/ move to the cloud made things worse RDBS don't scale easily into the horizontal manner.
- #6 many noSql vendorsStrong ConsistencyAll clients see the same view, even in presence of updatesHigh AvailabilityAll clients can find some replica of the data, even in the presence of failuresPartition-toleranceThe system properties hold even when the system is partitionedThe CAP theorem states that you can always have only two of the above three CAP properties. The ACID system serves consistency. Hence Amazon Dynamo providing Availability and Partitioning properties, consistency is eventually achieved.
- #7 Columns families - cassandra (scale much better) table of column families
- #9 Key Value stores (redis) - like HashMapRedis, Riak, Project Voldemort, Membase, Amazon SimpleDB, Amazon Dynamo, MemcachedDB
- #10 Documents store (jason stores) - mongoDB, CouchDb,RavenDB, JackRabbit, Terrastore - i will show in a few minutesMongoDB Infrastructure APIMongoDB Query API
- #12 http://www.infoq.com/articles/Transition-RDBMS-NoSQL
- #21 so much choices, so many APIs - they are very different, not all of the those stores have Java driversfrom Java developers perspective, how can we approach this, how Java developer can get easy access to those stores, without drill down to all the details of the stores.
- #22 Spring Data makes it easier to build Spring-powered applications that use new data access technologies such as non-relational databases, map-reduce frameworks, and cloud based data services as well as provide improved support for relational database technologies.Spring Data is an umbrella open source project which contains many subprojects that are specific to a given database. The projects are developed by working together with many of the companies and developers that are behind these exciting technologies.
- #25 Spring Data supported modules - pics: key value stores - riak, redis (vmware product, not surprise) documents - mongodb, couchbase (active development is on mongodb)hadoop (big data manipulation), neo4j support for relational stores: JDBC and JPA (consists only a repository)
- #26 Spring Data supported modules - pics: key value stores - riak, redis (vmware product, not surprise) documents - mongodb, couchbase (active development is on mongodb)hadoop (big data manipulation), neo4j support for relational stores: JDBC and JPA (consists only a repository)
- #27 Spring Data supported modules - pics: key value stores - riak, redis (vmware product, not surprise) documents - mongodb, couchbase (active development is on mongodb)hadoop (big data manipulation), neo4j support for relational stores: JDBC and JPA (consists only a repository)
- #28 Spring Data supported modules - pics: key value stores - riak, redis (vmware product, not surprise) documents - mongodb, couchbase (active development is on mongodb)hadoop (big data manipulation), neo4j support for relational stores: JDBC and JPA (consists only a repository)
- #29 Spring Data supported modules - pics: key value stores - riak, redis (vmware product, not surprise) documents - mongodb, couchbase (active development is on mongodb)hadoop (big data manipulation), neo4j support for relational stores: JDBC and JPA (consists only a repository)
- #30 http://www.infoq.com/articles/spring-data-intro
- #31 A very core theme of the Spring Data project available through all of the stores is support for configuring resources to access the stores. This supported is mainly implemented as XML namespace and support classes for Spring JavaConfig and will allow us to easily setup access to a MongoDB, an embedded Neo4j instance and the like. Also integration with core Spring functionality like JMX is provided which means that some stores will expose statistics through their native API which will be exposed to JMX via Spring Data.
- #32 Most of the NoSQL Java APIs do not provide support to map domain objects onto the stores data abstractions (documents in MongoDB, nodes and relationships for Neo4j). So when working with the native Java drivers you would usually have to write a significant amount of code to map data onto your domain objects of your application when reading and vice versa on writing. Thus, a very core part of the Spring Data modules is a mapping and conversion API that allows obtaining meta-data about domain classes to be persistent as well as the actual conversion of arbitrary domain objects into store specific data types.
- #33 Most of the NoSQL Java APIs do not provide support to map domain objects onto the stores data abstractions (documents in MongoDB, nodes and relationships for Neo4j). So when working with the native Java drivers you would usually have to write a significant amount of code to map data onto your domain objects of your application when reading and vice versa on writing. Thus, a very core part of the Spring Data modules is a mapping and conversion API that allows obtaining meta-data about domain classes to be persistent as well as the actual conversion of arbitrary domain objects into store specific data types.
- #34 Most of the NoSQL Java APIs do not provide support to map domain objects onto the stores data abstractions (documents in MongoDB, nodes and relationships for Neo4j). So when working with the native Java drivers you would usually have to write a significant amount of code to map data onto your domain objects of your application when reading and vice versa on writing. Thus, a very core part of the Spring Data modules is a mapping and conversion API that allows obtaining meta-data about domain classes to be persistent as well as the actual conversion of arbitrary domain objects into store specific data types.
- #35 Most of the NoSQL Java APIs do not provide support to map domain objects onto the stores data abstractions (documents in MongoDB, nodes and relationships for Neo4j). So when working with the native Java drivers you would usually have to write a significant amount of code to map data onto your domain objects of your application when reading and vice versa on writing. Thus, a very core part of the Spring Data modules is a mapping and conversion API that allows obtaining meta-data about domain classes to be persistent as well as the actual conversion of arbitrary domain objects into store specific data types.
- #36 any one knows jdbctemplate in spring? Its heavily used in spring. This is the central class in the JDBC core package. This is the class that provides an API. It simplifies the use of JDBC and helps to avoid common errors. It executes core JDBC workflow, leaving application code to provide SQL and extract results. This class executes SQL queries or updates, initiating iteration over ResultSets and catching JDBC exceptions and translating them to the generic, more informative exception hierarchy defined in the org.springframework.dao package. Spring takes this concept and provided templates for noSQL stores you can find MongoTemplate, RedisTemplateOn top of that we'll find opinionated APIs in the shape of template pattern implementations already well known from Spring's JdbcTemplate, JmsTemplate etc. Thus, there is a RedisTemplate, a MongoTemplate and so on. As you probably already know these templates offer helper methods that allow us to execute commonly needed operations like persisting an object with a single statement while automatically taking care of appropriate resource management and exception translation. Beyond that they expose callback APIs that allow you to access the store native APIs while still getting exceptions translated and resources managed properly.
- #37 any one knows jdbctemplate in spring? Its heavily used in spring. This is the central class in the JDBC core package. This is the class that provides an API. It simplifies the use of JDBC and helps to avoid common errors. It executes core JDBC workflow, leaving application code to provide SQL and extract results. This class executes SQL queries or updates, initiating iteration over ResultSets and catching JDBC exceptions and translating them to the generic, more informative exception hierarchy defined in the org.springframework.dao package. Spring takes this concept and provided templates for noSQL stores you can find MongoTemplate, RedisTemplateOn top of that we'll find opinionated APIs in the shape of template pattern implementations already well known from Spring's JdbcTemplate, JmsTemplate etc. Thus, there is a RedisTemplate, a MongoTemplate and so on. As you probably already know these templates offer helper methods that allow us to execute commonly needed operations like persisting an object with a single statement while automatically taking care of appropriate resource management and exception translation. Beyond that they expose callback APIs that allow you to access the store native APIs while still getting exceptions translated and resources managed properly.
- #38 any one knows jdbctemplate in spring? Its heavily used in spring. This is the central class in the JDBC core package. This is the class that provides an API. It simplifies the use of JDBC and helps to avoid common errors. It executes core JDBC workflow, leaving application code to provide SQL and extract results. This class executes SQL queries or updates, initiating iteration over ResultSets and catching JDBC exceptions and translating them to the generic, more informative exception hierarchy defined in the org.springframework.dao package. Spring takes this concept and provided templates for noSQL stores you can find MongoTemplate, RedisTemplateOn top of that we'll find opinionated APIs in the shape of template pattern implementations already well known from Spring's JdbcTemplate, JmsTemplate etc. Thus, there is a RedisTemplate, a MongoTemplate and so on. As you probably already know these templates offer helper methods that allow us to execute commonly needed operations like persisting an object with a single statement while automatically taking care of appropriate resource management and exception translation. Beyond that they expose callback APIs that allow you to access the store native APIs while still getting exceptions translated and resources managed properly.
- #39 any one knows jdbctemplate in spring? Its heavily used in spring. This is the central class in the JDBC core package. This is the class that provides an API. It simplifies the use of JDBC and helps to avoid common errors. It executes core JDBC workflow, leaving application code to provide SQL and extract results. This class executes SQL queries or updates, initiating iteration over ResultSets and catching JDBC exceptions and translating them to the generic, more informative exception hierarchy defined in the org.springframework.dao package. Spring takes this concept and provided templates for noSQL stores you can find MongoTemplate, RedisTemplateOn top of that we'll find opinionated APIs in the shape of template pattern implementations already well known from Spring's JdbcTemplate, JmsTemplate etc. Thus, there is a RedisTemplate, a MongoTemplate and so on. As you probably already know these templates offer helper methods that allow us to execute commonly needed operations like persisting an object with a single statement while automatically taking care of appropriate resource management and exception translation. Beyond that they expose callback APIs that allow you to access the store native APIs while still getting exceptions translated and resources managed properly.
- #40 So who is written a GenericDao? On top of that we have Repositories support. So an idea here is that usually you implements some kind of data layer, just having interface and then implementation for different store, like JPA store, mongo store and etc.. and most of the code written is there is a boilerplate.To ease that even more Spring Data provides a repository abstraction on top of the template implementation that will reduce the effort to implement data access objects to a plain interface definition for the most common scenarios like standard CRUD operations as well as executing queries in case the store supports that. This abstraction is actually the most top layer and blends the APIs of the different stores as much as reasonably possible.so we have here an interface based programming model, so you have an interface for the queries you want to trigger and then those methods will be generated without a need to implement this interface. I will show you later on... Уже прошло несколько лет с тех пор, как появился JPA. Работа с Entity Manager увлекательна, но разработчики пишут красивый API, а подробности работы с базой данных скрывают. При этом частая проблема - дублирование имплементации, когда из одного DAO в другой у нас плавно перекочёвывает один и тот же код, в лучшем случае этот код переносится в абстрактный базовый DAO. Spring Data коренным образом решает проблему - при его использовании остаётся только API на уровне интерфейсов, вся имплементация создаётся автоматически с использованием AOP.http://atamanenko.blogspot.com/2012/02/jpa-spring-data-jpa.htmlTo ease that even more Spring Data provides a repository abstraction on top of the template implementation that will reduce the effort to implement data access objects to a plain interface definition for the most common scenarios like standard CRUD operations as well as executing queries in case the store supports that. This abstraction is actually the most top layer and blends the APIs of the different stores as much as reasonably possible. Thus the store specific implementations of it share quite a lot of commonalities.
- #41 So who is written a GenericDao? On top of that we have Repositories support. So an idea here is that usually you implements some kind of data layer, just having interface and then implementation for different store, like JPA store, mongo store and etc.. and most of the code written is there is a boilerplate.To ease that even more Spring Data provides a repository abstraction on top of the template implementation that will reduce the effort to implement data access objects to a plain interface definition for the most common scenarios like standard CRUD operations as well as executing queries in case the store supports that. This abstraction is actually the most top layer and blends the APIs of the different stores as much as reasonably possible.so we have here an interface based programming model, so you have an interface for the queries you want to trigger and then those methods will be generated without a need to implement this interface. I will show you later on... Уже прошло несколько лет с тех пор, как появился JPA. Работа с Entity Manager увлекательна, но разработчики пишут красивый API, а подробности работы с базой данных скрывают. При этом частая проблема - дублирование имплементации, когда из одного DAO в другой у нас плавно перекочёвывает один и тот же код, в лучшем случае этот код переносится в абстрактный базовый DAO. Spring Data коренным образом решает проблему - при его использовании остаётся только API на уровне интерфейсов, вся имплементация создаётся автоматически с использованием AOP.http://atamanenko.blogspot.com/2012/02/jpa-spring-data-jpa.htmlTo ease that even more Spring Data provides a repository abstraction on top of the template implementation that will reduce the effort to implement data access objects to a plain interface definition for the most common scenarios like standard CRUD operations as well as executing queries in case the store supports that. This abstraction is actually the most top layer and blends the APIs of the different stores as much as reasonably possible. Thus the store specific implementations of it share quite a lot of commonalities.
- #42 So who is written a GenericDao? On top of that we have Repositories support. So an idea here is that usually you implements some kind of data layer, just having interface and then implementation for different store, like JPA store, mongo store and etc.. and most of the code written is there is a boilerplate.To ease that even more Spring Data provides a repository abstraction on top of the template implementation that will reduce the effort to implement data access objects to a plain interface definition for the most common scenarios like standard CRUD operations as well as executing queries in case the store supports that. This abstraction is actually the most top layer and blends the APIs of the different stores as much as reasonably possible.so we have here an interface based programming model, so you have an interface for the queries you want to trigger and then those methods will be generated without a need to implement this interface. I will show you later on... Уже прошло несколько лет с тех пор, как появился JPA. Работа с Entity Manager увлекательна, но разработчики пишут красивый API, а подробности работы с базой данных скрывают. При этом частая проблема - дублирование имплементации, когда из одного DAO в другой у нас плавно перекочёвывает один и тот же код, в лучшем случае этот код переносится в абстрактный базовый DAO. Spring Data коренным образом решает проблему - при его использовании остаётся только API на уровне интерфейсов, вся имплементация создаётся автоматически с использованием AOP.http://atamanenko.blogspot.com/2012/02/jpa-spring-data-jpa.htmlTo ease that even more Spring Data provides a repository abstraction on top of the template implementation that will reduce the effort to implement data access objects to a plain interface definition for the most common scenarios like standard CRUD operations as well as executing queries in case the store supports that. This abstraction is actually the most top layer and blends the APIs of the different stores as much as reasonably possible. Thus the store specific implementations of it share quite a lot of commonalities.
- #43 On top of that we have Repositories support. So an idea here is that usually you implements some kind of data layer, just having interface and then implementation for different store, like JPA store, mongo store and etc.. and most of the code written is there is a boilerplate.So who is written a GenericDao? so we have here an interface based programming model, so you have an interface for the queries you want to trigger and then those methods will be generated without a need to implement this interface. I will show you later on... Уже прошло несколько лет с тех пор, как появился JPA. Работа с Entity Manager увлекательна, но разработчики пишут красивый API, а подробности работы с базой данных скрывают. При этом частая проблема - дублирование имплементации, когда из одного DAO в другой у нас плавно перекочёвывает один и тот же код, в лучшем случае этот код переносится в абстрактный базовый DAO. Spring Data коренным образом решает проблему - при его использовании остаётся только API на уровне интерфейсов, вся имплементация создаётся автоматически с использованием AOP.http://atamanenko.blogspot.com/2012/02/jpa-spring-data-jpa.htmlTo ease that even more Spring Data provides a repository abstraction on top of the template implementation that will reduce the effort to implement data access objects to a plain interface definition for the most common scenarios like standard CRUD operations as well as executing queries in case the store supports that. This abstraction is actually the most top layer and blends the APIs of the different stores as much as reasonably possible. Thus the store specific implementations of it share quite a lot of commonalities.
- #44 On top of that we have Repositories support. So an idea here is that usually you implements some kind of data layer, just having interface and then implementation for different store, like JPA store, mongo store and etc.. and most of the code written is there is a boilerplate.So who is written a GenericDao? so we have here an interface based programming model, so you have an interface for the queries you want to trigger and then those methods will be generated without a need to implement this interface. I will show you later on... Уже прошло несколько лет с тех пор, как появился JPA. Работа с Entity Manager увлекательна, но разработчики пишут красивый API, а подробности работы с базой данных скрывают. При этом частая проблема - дублирование имплементации, когда из одного DAO в другой у нас плавно перекочёвывает один и тот же код, в лучшем случае этот код переносится в абстрактный базовый DAO. Spring Data коренным образом решает проблему - при его использовании остаётся только API на уровне интерфейсов, вся имплементация создаётся автоматически с использованием AOP.http://atamanenko.blogspot.com/2012/02/jpa-spring-data-jpa.htmlTo ease that even more Spring Data provides a repository abstraction on top of the template implementation that will reduce the effort to implement data access objects to a plain interface definition for the most common scenarios like standard CRUD operations as well as executing queries in case the store supports that. This abstraction is actually the most top layer and blends the APIs of the different stores as much as reasonably possible. Thus the store specific implementations of it share quite a lot of commonalities.
- #45 and the last one, Querydsl