Разделение jmix приложения на репозиторный/сервисный/слой представления

Здравствуйте. У меня есть готовое jmix приложение. Проблема в том, что все datagrid элементы, все поля ввода и тд, в общем вся работа с данными - все интегрировано в xml и java конфигурацию вьюх по умолчанию. мне нужно разделить все это дело на слои. Не понимаю как - только если полностью писать с нуля свою реализацию и все переделывать. Сейчас это имеет вид стандартного jmix приложения по самоучителю.

Добрый день!

Вы можете вынести загрузку/сохранение данных из экранов в слой сервисов или репозиториев если создадите в экране loadDelegate и saveDelegate.

В версии Jmix 2.3, которая скоро выйдет, появятся стандартные шаблоны, по которым можно будет генерировать экраны сразу с делегатами для имеющихся репозиториев.

С уважением,
Константин

Разобрался с loadDelegate. Переделал таким образом экраны EntityList. В экранах EntityDetail не нашел saveDelegate. Можете подсказать как это реализовать?

В экранах EntityDetail не нашел saveDelegate. Можете подсказать как это реализовать?

2 способа сгенерировать в студии:

  1. Либо выделите в структуре элемент и перейдите на вкладку Handlers инспектора
  2. Либо в классе экрана (контроллере) нажмите Generate Handler и найдите Data context handlers → saveDelegate.

Заранее извиняюсь за глупые вопросы… Был бы очень благодарен за прояснение двух моментов:

  1. В самоучителе используется вот такая конфигурация:
<data>
        <collection id="usersDc"
                    class="com.company.hr_crm.entity.User">
            <fetchPlan extends="_base"/>
            <loader id="usersDl" readOnly="true">
                <query>
                    <![CDATA[select e from User e order by e.username]]>
                </query>
            </loader>
        </collection>
    </data>

В контексте разделения на слои, мне кажется, что это не очень хорошая практика. Можно ли обойтись без использования query в xml? Проблема в том что в loadContext в любом случае будет query, так как я использую genericFilter. И вот не могу понять, как полноценно избавить слой представления от такой конфигурации. Тут ведь даже используемый класс указывается…

  1. Второй вопрос. По поводу saveDelegate. В документации к данному хэндлеру, написано return “обращение к сервису”. В случае удаления и метода delegate для deleteAction, это void функции. Я так понимаю, это нужно для обратной связи. В моем случае это:
    а) при попытке создать пользователя с неуникальным именем пользователя
    б) при несовпадении паролей (речь про экран UserDetail)
    Но в документации нет информации о том что должен возвращать метод, и как с этим работать. То есть, да, я сейчас могу делегировать сохранение, но как тогда обрабатывать описанные выше ситуации?

Заранее благодарю Вас за уделенное время! Не знаю, что бы делал без этого форума…

Вопросы абсолютно разумные, не стоит извиняться.

  1. Вы говорите что хотите использовать GenericFilter. Он формирует дерево Condition внутри LoadContext. Как вы планируете его обрабатывать?
    Самое простое - передать в итоге LoadContext в DataManager, это можно сделать где-то внутри вашего сервиса. Вопрос только, нужен ли тогда вообще этот сервис?
    Другой вариант - вызвать Data Repository. В версии 2.3 (релиз-кандидат уже доступен) в методы репозиториев можно передавать данные из LoadContext. Вы можете увидеть это если сгенерируете новые экраны с включенным флагом Use Data Repositories (см. What’s New :: Jmix Documentation).

  2. Спасибо за замечание. В документации теперь есть описание ожидаемого результата saveDelegate, см. DataContext :: Документация Jmix