С точки зрения дизайна, и для приложения среднего размера, «нормально» использовать ваши объекты таблицы в вашем бизнес-логическом слое? Когда я говорю хорошо, я действительно имею в виду, что это не плохая практика.Использование Slick with Scala (с Playframwork 2.3)
Существует множество программных паттернов, таких как шаблон хранилища, активный шаблон записи и т. Д. И я просто не уверен, что они подходят для такого языка, как Scala.
На мой вкус это даже лучше, чем репозиторий или активный образец записи. С активной записью вам нужно будет добавить magic к самому объекту, трудно отделить от него не очень прозрачно. С шаблоном репозитория вы получите множество небольших репозиториев, для каждой сущности, которые сами по себе очень немыслимы, и все их функции состоят в том, чтобы обернуть вызовы в базу данных развязанным образом, главным образом, чтобы иметь возможность тестировать на макет или in-memory db.
Но когда вы используете табличные запросы на своем уровне обслуживания (или Business Logic Layer, если хотите), вы не жертвуете тестируемостью (или связью вошь). Сама функциональность базы данных абстрагируется в файле scala.slick.driver.JdbcProfile, поэтому вам не нужно делать другую абстракцию, чтобы исключить ее.
Конечно, лучше всего группировать все запросы, которые используются более одного раза рядом с определением таблицы и импортировать их в ваши службы, но это не совсем репозиторий, а всего лишь множество композиционных запросов.
Надеюсь, это поможет.
Это законный образец, если вы решите использовать объекты Slick Table и TableQuery непосредственно в вашем бизнес-слое. Slick абстрактно выводит код низкого уровня db. использование API-интерфейса Slick не сильно отличается от использования обычных API Scala, поэтому не должно быть оснований использовать запись, репозиторий или любые другие традиционные шаблоны при использовании Slick.
При составлении Queries Мне представляется полезным использовать неявные классы расширения запроса. вы можете найти некоторые подробности об этом стиле here и here
Это очень полезно, однако я не полностью убежден. Причина, по которой я очень беспокоюсь, состояла в том, что в настоящее время я использую JPA (Hibernate), и сейчас я пересматриваю свой код, чтобы перейти на Slick. Сейчас его довольно сложно из-за плохого первоначального дизайна. Мне было интересно, если я напрямую использую объект Slick Table, не беспокоясь о связи, и в будущем я решил перейти на другую технологию, это может быть очень сложно. –
@vitalii, как бы вы издевались над гладкими звонками в модульных тестах? – Teimuraz
@moreo почему, я бы просто ввел тестовое соединение с базой данных (или тестовое соединение). Запросы отключаются от соединения, поэтому я могу иметь запросы на уровне сервиса и все еще иметь возможность тестировать службы без реального db. – vitalii