Spring Data - Intro (Odessa Java TechTalks)

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