О доменном моделировании с использованием Spring Data Neo4j

А вот как будет выглядеть наше представление деталей:

Отношения между человеком и проектом имеют связанную роль. Эти отношения также являются основой для списка соавторов: два человека являются соавторами, если есть хотя бы один проект, членами которого они являются.

Наших простых требований должно быть достаточно, чтобы показать, каково это — писать код Spring Data Neo4j.

Создание сущностей Person и ProjectMembership

Сначала мы создадим Человека. Я подавил аннотации валидации и JAXB, поскольку они не имеют отношения к нашим текущим целям:

package org.skydingo.skybase.model;

import java.util.Set;
import org.neo4j.graphdb.Direction;
import org.skydingo.skybase.model.relationship.ProjectMembership;
import org.springframework.data.neo4j.annotation.*;
import org.springframework.data.neo4j.support.index.IndexType;

@NodeEntity
public class Person implements Comparable<Person> {
    @GraphId private Long id;

    @Indexed(indexType = IndexType.FULLTEXT, indexName = "searchByUsername")
    private String username;

    private String firstName, lastName, title, workPhone, mobilePhone, email;

    @RelatedTo(type = "REPORTS_TO")
    private Person manager;

    @RelatedTo(type = "REPORTS_TO", direction = Direction.INCOMING)
    private Set<Person> directReports;

    @RelatedToVia(type = "MEMBER_OF")
    private Set<ProjectMembership> memberships;

    public Long getId() { return id; }

    public void setId(Long id) { this.id = id; }

    public String getUsername() { return username; }

    public void setUsername(String username) { this.username = username; }

    ... other accessor methods ...

    public Person getManager() { return manager; }

    public void setManager(Person manager) { this.manager = manager; }

    public Set<Person> getDirectReports() { return directReports; }

    public void setDirectReports(Set<Person> directReports) {
        this.directReports = directReports;
    }

    public Iterable<ProjectMembership> getMemberships() { return memberships; }

    public ProjectMembership memberOf(Project project, String role) {
        ProjectMembership membership = new ProjectMembership(this, project, role);
        memberships.add(membership);
        return membership;
    }

    ... equals(), hashCode(), compareTo() ...
}

Есть много аннотаций, которые мы используем, чтобы создать структуру. Начнем с узлов и их свойств. Затем мы рассмотрим простые отношения между узлами. Затем мы рассмотрим так называемые сущности отношений, которые в основном являются причудливыми отношениями. Во-первых, вот абстрактное представление нашей модели предметной области:

Теперь давайте посмотрим на некоторые детали.

Узлы и их свойства. Когда у нас есть объект на основе узла, сначала мы аннотируем его аннотацией @NodeEntity. Большинство простых свойств узлов (т. Е. Свойств, которые не являются связями с другими узлами) подойдут для поездки. Обратите внимание, что мне не нужно было комментировать firstName, lastName, email и т. Д. Spring Data Neo4j будет обрабатывать отображение там автоматически.

Однако есть несколько исключений. Во-первых, я добавил @GraphId в свое свойство id. Это говорит Spring Data Neo4j, что это идентификатор, который мы можем использовать для поиска. Другая — аннотация @Indexed, которая (неожиданно) создает индекс для рассматриваемого свойства. Это полезно, когда вам нужна альтернатива поиску по идентификатору.

Теперь посмотрим на отношения. Говоря в широком смысле, существуют простые отношения и более сложные отношения. Начнем с простых.

Простые отношения. На низком уровне Neo4j является базой данных графа, поэтому мы можем говорить о графе в теоретических терминах графа, таких как узлы, ребра, направленные ребра, DAG и все такое. Но здесь мы используем графики для моделирования предметной области, поэтому мы интерпретируем понятия низкоуровневых графов в терминах понятий моделирования предметной области более высокого уровня. Язык, который использует Spring Data Neo4j, — это «сущность узла» для узлов и «связь» для ребер.

Наш Person CI имеет простые отношения, называемые REPORTS_TO, которые связывают людей, чтобы мы могли моделировать иерархии отчетов. Person имеет два поля для этих отношений: manager и directReports. Это противоположные сайты с одинаковыми отношениями. Мы используем @RelatedTo (type = «REPORTS_TO») для аннотирования этих полей. У аннотации также есть элемент direction, значением по умолчанию которого является Direction.OUTGOING, что означает, что этот узел является хвостовым краем. Вот почему мы явно указываем direction = Direction.INCOMING для поля directReports.

(Немного в стороне: есть аннотация @Fetch — мы увидим ее чуть позже — которая говорит Spring Data Neo4j о необходимости загружать связанный объект. По какой-то причине мне не нужно использовать его для отношений менеджера и прямых отчетов, и я не уверен почему. Если кто-то знает, я был бы признателен за объяснение.)

Отношения сущностей. Помимо отношений REPORTS_TO между людьми, нам важны отношения MEMBER_OF между людьми и проектами. Это более интересно, чем отношение REPORTS_TO, потому что MEMBER_OF имеет ассоциированное свойство — роль — это аналогично добавлению столбца в таблицу ссылок в СУБД, как я упоминал в своем ответе Бригу в предыдущем посте. Метод Person.memberOf () предоставляет удобный способ назначить человека проекту, используя специальную «сущность отношения» ProjectMembership. Вот код:

package org.skydingo.skybase.model.relationship;

import org.skydingo.skybase.model.Person;
import org.skydingo.skybase.model.Project;
import org.springframework.data.neo4j.annotation.*;

@RelationshipEntity(type = "MEMBER_OF")
public class ProjectMembership {
    @GraphId private Long id;
    @Fetch @StartNode private Person person;
    @Fetch @EndNode private Project project;
    private String role;

    public ProjectMembership() { }

    public ProjectMembership(Person person, Project project, String role) {
        this.person = person;
        this.project = project;
        this.role = role;
    }

    public Person getPerson() { return person; }

    public void setPerson(Person person) { this.person = person; }

    public Project getProject() { return project; }

    public void setProject(Project project) { this.project = project; }

    public String getRole() { return role; }

    public void setRole(String role) { this.role = role; }

    ... equals(), hashCode(), toString() ...

}

ProjectMembership, как Person, является сущностью, но это сущность отношений. Мы используем @RelationshipEntity (type = «MEMBER_OF»), чтобы пометить это как объект отношения, и, как и в случае с Person, мы используем @GraphId для свойства id. Аннотации @StartNode и @EndNode указывают хвостовую часть и голову соответственно. @Fetch говорит Spring Data Neo4j загружать узлы с нетерпением. По умолчанию Spring Data Neo4j не очень загружает отношения, поскольку рискует загрузить весь график в память.

Создайте PersonRepository

Вот наш интерфейс PersonRepository:

package org.skydingo.skybase.repository;

import java.util.Set;
import org.skydingo.skybase.model.Person;
import org.skydingo.skybase.model.Project;
import org.springframework.data.neo4j.annotation.Query;
import org.springframework.data.neo4j.repository.GraphRepository;

public interface PersonRepository extends GraphRepository<Person> {

    Person findByUsername(String username);

    @Query("start project=node({0}) match project<--person return person")
    Set<Person> findByProject(Project project);

    @Query(
        "start person=node({0}) " +
        "match person-[:MEMBER_OF]->project<-[:MEMBER_OF]-collaborator " +
        "return collaborator")
    Set<Person> findCollaborators(Person person);
}

В последнем посте я отметил, что все, что нам нужно сделать, это расширить интерфейс GraphRepository; Spring Data генерирует реализацию автоматически.