Database Reference
In-Depth Information
Who implemented my interface?
The astute among you may have realized that we never actually defined any concrete im-
plementationforthe
UserRepository
interface.WesimplyinjecteditthroughSpring's
@Autowired
annotation andthen usedit, somehow managing toread andsave the
User
domain entities along the way. So, if we never provided any implementation, who did, and
how does this work?
There's no magic involved here. What's happening is that SDN used the initial packages
youprovidedinyourXMLconfigurationtosearchforyourrepositorydefinitions,andthen
dynamically created a proxy for you that implements your interface and makes it avail-
able as a Spring bean. This proxy does all the hard work of implementing the functionality
defined in the core interfaces. You get a whole bunch of functionality simply by extending
one interface!
Repositories are a step up from the
Neo4jTemplate
class in that they also provide im-
plementations for a lot of boilerplate code, but in a far more domain-targeted manner.
9.3.4. Other options
Besides using the
Neo4jTemplate
class or repositories, there's a third approach avail-
able when saving entities. This involves calling a persistence method on the entity itself.
We'll cover this in
section 9.4.2
as it's only available when making use of the advanced
mapping mode, but it's listed here for completeness.
There may also be cases when your domain object needs to load data from multiple data
stores,theso-called
cross-store persistence
scenario.Perhapssomeofyourdataisstoredin
Neo4j and the rest in MySQL. You'll be happy to know that SDN also caters to cross-store
persistence, although we won't be covering how to do this in this topic. More information
about cross-store persistence can be found in the core Neo4j SDN documentation.
Can SDN and native Neo4j play nicely together?
