Это должно сработать:
<% my_param ||= 'default value' %>
Часть, содержащая это, может быть визуализирована с или без предоставления my_param
.
Думаю, это должна быть служба.
Эванс рекомендует в своей книге, что, когда вы сомневаетесь, следует ли помещать метод, который «плохо пахнет» внутри класса, потому что вы думаете, что он не принадлежит ему, создавайте класс ServiceFoo с операцией внутри.
void DoLongInvolvedTask();
Я не вижу ничто плохого с помещением объемных задач как методы в Вашем репозитории. Они ничего не пропускают. Начинание Объемной операции не подразумевает базы данных определенные операции, это - то, если Ваш метод не что-то как ReBuildMSSQLIndexesOnMyBigTable ().
Вы не должны сделать, чтобы любой сохранил, получил логику в объекте области (я предполагаю, что Вы используете модель предметной области). Это - ответственность Репозитория. Таким образом, Ваш объемный метод принадлежит репозитория.
При использовании ORM затем репозитории не будут зависеть от базы данных. они выступали бы, передают весь запрос к уровню ORM.
Если бы Вы пишете свой собственный картопостроитель затем, репозиторий передал бы запрос к картопостроителю для объекта. И я думаю, что эта связь в порядке.
То, что вам нужно, называется службой в доменно-ориентированном дизайне. Сервисы используются для моделирования процедурных задач. Операция массового обновления, подобная описанной вами, была бы идеальным кандидатом для службы.
РЕДАКТИРОВАТЬ: Исходная ссылка исчезла. Вы можете найти глоссарий терминов DDD здесь, но он не так полезен, как исходная страница. http://dddcommunity.org/resources/ddd_terms/