Your SlideShare is downloading. ×
  • Like
Spring Data - Intro (Odessa Java TechTalks)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Spring Data - Intro (Odessa Java TechTalks)

  • 861 views
Published

Igor Anishchenko …

Igor Anishchenko
Odessa Java TechTalks
Lohika - September, 2012

This session starts with a high-level look at all that the Spring Data project has to offer.
Then we’ll dive deeper into a few select Spring Data modules, including Spring Data JPA, Spring Data MongoDB and Spring Data Redis.
Implementing a data access layer of an application has been cumbersome for quite a while. Too much boilerplate code had to be written!
Spring Data is a project that makes it easier to build Spring-powered applications that use new data, offering a reasonably consistent programming model regardless of which type of database you choose.
In addition to supporting the new “NoSQL” databases such as document and graph databases, Spring Data also greatly simplifies working with RDBMS-oriented datastores using JPA -simplifies the development of creating a JPA-based data access layer.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
861
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
22
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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.
  • 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.
  • Columns families - cassandra (scale much better) table of column families
  • Key Value stores (redis) - like HashMapRedis, Riak, Project Voldemort, Membase, Amazon SimpleDB, Amazon Dynamo, MemcachedDB
  • Documents store (jason stores) - mongoDB, CouchDb,RavenDB, JackRabbit, Terrastore - i will show in a few minutesMongoDB Infrastructure APIMongoDB Query API
  • http://www.infoq.com/articles/Transition-RDBMS-NoSQL
  • 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.
  • 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.
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • http://www.infoq.com/articles/spring-data-intro
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • and the last one, Querydsl

Transcript

  • 1. Spring Data Igor Anishchenko Lohika - September, 2012
  • 2. RelationalDatabase
  • 3. Clouds
  • 4. Scaling
  • 5. Column families
  • 6. Graphs
  • 7. Key Value
  • 8. Documents
  • 9. MongoDBDocument Database JSON documents JSON queries
  • 10. MongoDBThe most important difference is the data model:
  • 11. Mongo data modelA Mongo system (see deployment above) holds a setof 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 likestring, integer, float, timestamp, binary, etc., a document, or an array of values
  • 12. MongoDB• Flexible data model• 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
  • 13. Mongo InfrastructureAPI
  • 14. Mongo Query API
  • 15. JPA?
  • 16. " This document is the specification of theJava API for the management of persistenceand object/relational mapping with Java EEand Java SE. The technical objective of thiswork is to provide an object/relationalmapping facility for the Java applicationdeveloper using a Java domain model to man-age a relational database.
  • 17. " This document is the specification of theJava API for the management of persistenceand object/relational mapping with JavaEE and Java SE. The technical objective ofthis work is to provide anobject/relational mapping facility forthe Java application developer using a Javadomain model to man- age a relationaldatabase.
  • 18. JPA?
  • 19. Decision Time? As a developer - what are you looking for?
  • 20. Spring Data
  • 21. Mission statement“… provides a familiar andconsistent Spring-based programmingmodel for NoSQL and relational storeswhile retaining store-specificfeatures and capabilities”
  • 22. ... history• The Spring 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
  • 23. Spring Data JDBC JPA support for relational stores...
  • 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. Core componentsBuilding blocks of Spring Data modules
  • 29. 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
  • 30. Mapping
  • 31. ...Mapping• A very core 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
  • 32. JPA - Entitymapping
  • 33. Entity mapping - MongoDB
  • 34. Templates
  • 35. ... Templates• Heavily used 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
  • 36. MongoTemplate usage
  • 37. MongoOperation/-Template
  • 38. Repositories
  • 39. GenericDao
  • 40. ... Repositories• Provides a 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
  • 41. Repositories - JPA
  • 42. Repositories -MongoDB
  • 43. Querydsl
  • 44. DEMO
  • 45. Summary• Abstraction over stores drivers• Mapping support• Templates• Repositories / custom repositories• Querydsl• Spring namespace• Cross-store persistence
  • 46. ? ? ?? ? ?
  • 47. Resourceswww.springframework.org/spring-datahttp://github.com/SpringSource/spring-data-mongodbOReillys Open Feedback Publishing System is the book:http://ofps.oreilly.com/titles/9781449323950/http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis