Можно ли использовать классы менеджера в качестве синглетонов?

Question

Для каждого конкретного класса у меня есть класс менеджера. Этот класс имеет такие методы, как GetAll(), GetById(), Save и т. Д.

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

Это хороший подход? Или есть лучший альтернативный способ?

Answer 1

То, что вы называете классами менеджера, действительно "репозитории"

Репозитории должны работать только на уровне совокупного корня, а не по одному репозиторию на класс.Например, если у меня есть класс Order, который имеет коллекцию OrderItem, то существовал бы репозиторий Order, в котором были бы методы Get / GetAll - поскольку в этом случае Order является корнем agg.

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

В целом, я бы сказал, что ваш подход к одному «хранилищу» на сущность плохой - вместо этого придерживайтесь одного хранилища на совокупный корень.

Answer 2

Похоже, вы близки к реализации шаблона Repository , но не совсем так. Я бы посоветовал разобраться в этом. Я бы не стал делать их синглетами - слишком сложно их издеваться для ваших юнит-тестов, так что в итоге вы добавляете задние двери, чтобы победить синглтон для тестирования. Кеш делает хороший объект Singleton, но почему бы просто не разделить кеш таким образом, вместо умножения синглетонов?

Answer 3

Почему бы не включить их как часть конкретного класса, но статические? Сохраняет необходимость в двух отдельных классах.

Answer 4

Для целей тестирования / макетирования я бы советовал не использовать Singleton Manager / Repository.

Если вы хотите кэшировать результаты, я бы предложил делегировать их в выделенный класс Cache. Любая статическая магия может содержаться в классе Cache, и семантика вашего диспетчера / репозитория может быть чистой.

С точки зрения принципа единой ответственности, я должен быть в состоянии понять, как работает менеджер / репозиторий, не разбираясь в вашей схеме кэширования.