Grails: можно ли использовать объекты предметной области, если я не хочу ничего сохранять?

Классы домена Grails имеют несколько неправильных названий, поскольку уровень домена приложения обычно состоит из постоянных и непостоянных классов. Но доменные классы Grails всегда сохраняемы. У вас могут быть классы непостоянного домена (в традиционном смысле), но они должны быть в src/groovy или src/java. Это может расстраивать, потому что тогда уровень домена в приложении разделяется на два места. У нас были запросы на непостоянные классы домена, например. что-то вроде static persistent = false или что-то подобное, но это еще не реализовано.

Я думаю, что если вы хотите воспользоваться непостоянными функциями классов предметной области (например, проверка, внедрение зависимостей и т. д.), то неплохо иметь некоторые классы, которые могут поддерживаться базой данных, но не поддерживаются. Вам просто нужно задокументировать это в коде или иметь какое-то соглашение, например. специальная структура пакета или соглашение об именах. Если вы никогда не вызываете методы GORM, такие как save(), list(), findAllByFoo() и т. д., то доступа к базе данных не будет.

Что касается DTO, они могут быть не-DRY, но есть подключаемый модуль, который помогает — см. http://grails.org/plugin/dto< /а>. Он давно не обновлялся, но я уверен, что он все еще работает. У него есть приятная функция, позволяющая создать экземпляр DTO из экземпляра постоянного класса домена с синтаксисом domainObj as DTO. Вам необходимо синхронизировать изменения между классами, но первоначальная генерация DTO выполняется автоматически с помощью скрипта.

Я думаю, ты на правильном пути.

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

2. Модель, о которой говорят ваши друзья, на самом деле известна как Модель анемичной доменной области. данные отделены от логики вашей программы, и это было впервые описано Мартином Фаулером как анти-шаблон. Это разделение между логикой и данными очень часто используется в процедурном программировании, но не в объектно-ориентированном программировании (цель ООП прямо противоположна).

3 - Уменьшает повторное использование кода.

4 - Сложнее тестировать, если вам нужно инициализировать логику, отделенную от ваших данных. В то же время происходит утечка данных через вашу систему.

DTO - это то, что вы могли бы использовать, конечно. Но делать это не рекомендуется. Первоначально он был разработан для переноса данных (объектов) через процессы или уровни. Потом по какой-то причине люди начали использовать его между слоями, что не достойно. Делает вашу программу более сложной (после того, как вы разбросаете эти сущности по всему приложению) и обеспечивает глобальный доступ.

То, что вы делаете, называется моделью богатой предметной области, и с ее использованием проблем нет. Но, конечно, с этим нужно быть осторожным. Если вы видите, что ваш класс несет слишком много обязанностей, то, возможно, пришло время разработать другие классы, которые помогут (возможно, вы нарушаете SRP).

Посмотрите, как в Grails создаются объекты предметной области. Они поощряют вас писать богатые модели (проверка, транзакция БД и т. д.).