Класс записей с Findall с Spring Data JPA ⇐ JAVA

[Anonymous]

Я использую Springboot 3.4.2 (последний сейчас) Я могу создавать Restfful Controllers, которые получают доступ к службе, а затем мы делаем репозиторий, чтобы получить данные из базы данных, которые работают на 100%. Я полностью понимаю в том, почему мы не должны, в большинстве случаев, возвращать сущность в то, что называет Restful API. В некоторых случаях мы просто не хотим, чтобы данные возвращались, и в других случаях мы хотим собирать некоторые данные или делать вычисления по данным, и поэтому для этого будет использоваться DTO. Я полностью использую картирование объекта dto. < /P>
Теперь я вижу, что существует запись, и это с небольшими данными можно использовать в качестве DTO. Из того, что я прочитал, записи неизменны. Я прочитал много литературы по DTO (с Ломбоком) отличается от записей. Теперь, если я действительно хочу сохранить свои репозитории такими, какие они есть, я могу просто написать для себя код для карты от объектов в записи, но хотим ли мы это сделать? Из других примеров в Интернете я вижу, что мы можем использовать Spring Data JPA для загрузки данных непосредственно в записи, и если поля точно такие же, то отображение довольно проще. Если по некоторым причинам данные разные, то есть также способ исправить это, но я еще не там. Итак, у меня есть вопрос, и это небольшая проблема, но, возможно, я что -то упускаю. Итак, позвольте мне поставить код там. < /P>
@Entity
@Table(name = "company")
public class CompanyEntity implements Serializable
{
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "company_id")
private long companyId;
@Column(name = "active")
private boolean active;
@Column(name = "code")
private String companyCode;
@Column(name = "name")
private String companyName;
@Column(name = "description")
private String description;
@Column(name = "address1")
private String address1;
@Column(name = "address2")
private String address2;
@Column(name = "city")
private String city;
@Column(name = "state")
private String state;
@Column(name = "zip")
private String zip;
}
< /code>
А теперь у нас есть класс записи с одинаковыми точными полями: < /p>
public record CompanyRecord(long companyId, boolean active,
String companyCode,
String companyName, String description, String address1,
String address2, String city, String state, String zip)
implements Serializable {}
< /code>
И теперь у меня есть код репозитория: < /p>
@Repository("CompanyRepository")
public interface CompanyRepository extends JpaRepository
{
// This works great! No issus here!
public CompanyRecord findByCompanyId(long companyId);

// This works great! No issus here!
public List findAll();

// This does NOT work!
// IDE Reported Error:
// The return type is incompatible with ListCrudRepository.findAll()
public List findAll();

// This works great! No issus here!
List findByCompanyCode(String companyCode);
}
< /code>
Итак, я не знаю, является ли это скорее проблемой JparePository или как это исправить. Что еще более запутанно, так это тестирование JUNIT. < /P>
@Test
public void testFindById_Entity()
{
// works as expected, no problems
// surprising because the Repo wanted a CompanyRecord, and not an entity
long companyId = 1;
CompanyEntity companyEntity = companyRepository.findById(companyId).orElse(null);
assertNotNull(companyEntity);
}

@Disabled
@Test
public void testFindById_Record()
{
long companyId = 1;
// doesn't work, and gives an IDE error
// Type mismatch: cannot convert from CompanyEntity to CompanyRecord
// I would expect this to work since the interface specifically asks for a Record
CompanyRecord companyRecord = companyRepository.findById(companyId).orElse(null);
assertNotNull(companyRecord);
}

@Test
public void testFindByCode_Entity()
{
String companyCode = "IBM";
// does not work, AS EXPECTED since the interface wants a record
List companyEntityList = companyRepository.findByCompanyCode(companyCode);
assertNotNull(companyEntityList);
}

@Test
public void testFindByCode()
{
String companyCode = "IBM";
// this works as expected, the interface asks for a record
List companyRecordList = companyRepository.findByCompanyCode(companyCode);
assertNotNull(companyRecordList);
}

@Test
public void testFindAll_Entity()
{
// works as expected
List companyEntityList = companyRepository.findAll();
assertNotNull(companyEntityList);
}
< /code>
Я абсолютно вижу несколько очень запутанных моментов, пытающихся сделать это таким образом. Иногда вещь работает так, как я ожидал бы, а иногда нет. Заставляет меня чувствовать, что «запись» не совсем готова к прайм -тайм. Или я мог бы вернуться к ручному способу использования объекта для всей моей работы по репозитории и вручную CEAT -записей в службе, но я вижу, как использование записи в Spring Data JPA сохранит код шаблона.
У кого -нибудь есть похожие опыты, или может пролить больше света на запись Java в Spring Data JPA. Tha Baeldung Page - отличная информация, но в их примерах они определенно используют критериавину, и я не пойду по этой дороге. Я обычно использую HQL для моих конкретных запросов, и это может быть то, что я должен сделать. Здесь, и я полностью понимаю требования спящих сущностей и записей, я понимаю. Я также следил за другими комментариями об использовании jpql, и, хотя он, кажется, полностью не прошел мой тест на JUNIT, потому что конвертер не существовал, поэтому я получил эту ошибку. < /P>
Так что кажется, кажется , в интерфейсе репозитория: < /p>
// gives Convert error
@Query(value = "SELECT c from CompanyEntity c")
List companyRecordList findAllCustomerRecords();

// I think this might work but didn't test it
@Query(value = "SELECT new CompanyRecord( c.id, c.name, etc) from CompanyEntity c")
List companyRecordList findAllCustomerRecords();
< /code>
Итак, я знаю, что записи вышли из Java14 и более официально на Java16, но во всех местах, где я работал, мы никогда не использовали этот объект Record. Вся эта запись пришла ко мне, когда я работал над личным проектом, чтобы использовать GraphQL, и я был удивлен, увидев, что они использовали запись. Я пытался использовать записи таким образом, который, казалось, был отраслевым стандартным способом ведения дел, но я не думаю, что это еще довольно установлено. < /P>
На данный момент, я понимаю Зачем записи существует, но я не думаю, что мне нужно заменить DTO на записи. У нас есть различные инструменты, которые преобразуют Entity в DTO и наоборот, но, похоже, это еще не догнало записи. Я надеялся использовать Spring Data JPA для этого картирования, но кажется, что это требует некоторых усилий, и ИМХО, это не подходящее место для этого. < /P>
Итак, спасибо за все Ответы, я с нетерпением жду дополнительных мыслей по этому поводу, но я собираюсь строго соблюдать свой репозиторий с помощью сущности и вернуться к использованию DTO (с Lombok) и использовать Mapstruct или другие инструменты для моего отображения. Кажется более чистым раствором с меньшим кодом котла.

Подробнее здесь: https://stackoverflow.com/questions/794 ... g-data-jpa