Шаблон активной записи, шаблон репозитория и тестируемость (в Java) - PullRequest
Новая
       81

Шаблон активной записи, шаблон репозитория и тестируемость (в Java)

2 голосов
/ 15 апреля 2011

Каков был бы недостаток (например, с точки зрения тестируемости) следующего подхода, который направлен на получение лучших результатов от Active Record pattern и Repository pattern?

Каждый постоянный объект предоставляет методы save () и delete (), но не статические методы для загрузки самого себя или для загрузки списка похожих объектов: загрузка из верхних уровней выполняется путем непосредственного вызова репозитория, чтобы избежать статических методов в постоянные объекты.

Методы save () и delete () являются только фасадами, они делегируются в хранилище.

Действительно ли тестируемость является проблемой при таком подходе? Даже с чистым подходом Active Record: существуют ли информационные системы, в которых логика базы данных представляет лишь небольшую часть всей бизнес-логики, и где было бы интересно высмеивать доступ к базе данных?

РЕДАКТИРОВАНИЕ : для этого подхода необходимо, чтобы постоянные объекты наследовали от AbstractPersistentObject, который реализует "save ()" и "delete ()", и это предотвращает бизнес-наследование, но я читал, что лучше избегать бизнес наследование, и заменить его композицией, так что это может быть преимуществом, а не недостатком ...?

EDIT2 : Возможно, эта статья лучше объяснит, какие проблемы я пытаюсь решить: http://moleseyhill.com/blog/2009/07/13/active-record-verses-repository/

1 Ответ

6 голосов
/ 16 апреля 2011

Есть две вещи, которые вызывают некоторое беспокойство. Первая - это цитата (выделено мной):

[...] существуют ли информационные системы, в которых логика базы данных представляет собой лишь небольшую часть всей бизнес-логики , и где было бы интересно высмеивать доступ к базе данных?

Вы помещаете бизнес-логику в свою базу данных? Если так: не делайте этого, это делает очень трудным для насмешки над вашей базой данных. Вам придется дублировать (и поддерживать!) Всю бизнес-логику от базы данных до ваших ложных заданий, иначе ваши тесты бесполезны.

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

Размещение бизнес-логики в базе данных только создаст ненужную связь между вашей моделью и базой данных и существенно усложнит ваш уровень тестирования. Разделение проблем является ключевым здесь: модель фокусируется только на бизнес-логике, а база данных - только на постоянстве, и ничего больше.

Что подводит меня к следующей проблеме: зачем вам нужны методы save() и delete(), которые связаны с постоянством, в вашей доменной модели? Постоянство не относится к модели предметной области.

Я знаю, вы сказали, что эти методы делегируют в хранилище, поэтому модель предметной области (надеюсь) не содержит фактической логики персистентности. Но как он узнает , в какой репозиторий он должен делегировать?

Если вы вызываете локатор службы в методе save(), вы делаете невозможным сохранение объекта в нескольких репозиториях. Вы также скрываете зависимость от хранилища от вызывающей стороны, что я считаю плохой вещью.

Для решения этих проблем вы можете передать экземпляр хранилища методу save(), например: 

public class Foo extends AbstractPersistentObject {
    public void saveTo(IFooRepository repository) {
        repository.save(this);
    }
}

Но такой метод подразумевает, что у вызывающей стороны уже есть экземпляр репозитория, поэтому он может также вызвать метод save() непосредственно в репозитории. Любые методы сохранения в доменной модели будут устаревшими.

Возможно, я упрощаю вашу проблему. Чего вы пытаетесь достичь? Вам нужен только синтаксис entity.save() или вы пытаетесь решить большую проблему?

...