Có nên trả lại DAO của Kotlin hay không?

Question

Trước Kotlin/JPA, tôi sử dụng để viết lớp DAO của tôi như thế này:

public interface UserDao extends JpaRepository<User,Long> { 
    Optional<User> findBySsn(String ssn); 
} 

Và ở phía người gọi, nếu tôi muốn tìm một người nào đó hoặc tạo người dùng bằng cách SSN, tôi có thể viết này:

val user = userDao.findBySsn(value).orElseGet { 
    userDao.save(value) 
} 

Nó hoạt động tốt và trông thạo.

Nhưng kể từ Kotlin giới thiệu null-an toàn, có một cách khác thành ngữ (dao vẫn trong Java):

public interface UserDao extends JpaRepository<User,Long> { 

    Optional<User> findBySsn(String ssn); 

    @Query("select u from User u where u.ssn = :ssn") 
    @Nullable User findBySsnNullable(@Param("ssn") String ssn) 
} 

Và ở phía khách hàng:

val user = userDao.findBySsnNullable(value) 
     .takeIf{ it -> it != null}? : userDao.save(User(value)) 

Cả hai cách làm việc tốt. Nhưng tôi tự hỏi cái nào được ưa thích hơn? Có tốt cho Kotlin phụ thuộc vào thiết kế API Optional của Java8 không? Điểm yếu của dự án Kotlin là phụ thuộc vào (hoặc liên lạc thông qua) API Optional/Stream của Java8 (vì Kotlin có riêng)?

Kotlin có thể biên dịch sang JavaScript (Tôi chưa nghiên cứu). Nếu dự án phụ thuộc vào số Optional/Stream của Java, nó có vấn đề khi biên dịch sang JS không?

---- cập nhật ----

Theo Jetbrains

Không, mã phổ biến chỉ có thể phụ thuộc vào các thư viện phổ biến khác. Kotlin có không hỗ trợ dịch mã Java bytecode thành JS.

Answer 1

Tôi sẽ không sử dụng Optional nếu bạn không phải làm vậy. Nó chỉ thêm phí không cần thiết khi làm việc với các kiểu nullable là dễ đọc hơn và thành ngữ hơn trong Kotlin. Không có lợi thế khi sử dụng Optional ở Kotlin.

Đây là một cuộc thảo luận về rằng: https://discuss.kotlinlang.org/t/java-api-design-for-kotlin-consumption-optional-or-null/2455