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.
12. Mongo data model
A Mongo 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 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
17. " This document is 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 document is 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.
22. Mission statement
“… provides a familiar and
consistent Spring-based programming
model for NoSQL and relational stores
while retaining store-specific
features and capabilities”
23. ... 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
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...
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
32. ...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
36. ... 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
41. ... 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
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
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.