Да, ваш репозиторий должен возвращать все пять цен, а ваши объекты должны содержать бизнес-логику, которая решает, какой клиент получит какую цену. Объекты должны быть способны принять это решение независимо от того, откуда поступили их данные.
Этот подход также позволит вам проверить свою логику ценообразования независимо от ваших проблем с доступом к данным - например, с помощью «фиктивного» хранилища, вручную создавая продукт с уже заполненными пятью ценовыми полями или используя насмешку рамки, чтобы издеваться над вашими вызовами хранилища. Перемещение такого рода логики за пределы ваших бизнес-объектов - например, если поместить его на уровень доступа к данным, это может привести к появлению анти-паттерна, известного как Anemic Domain Model .
РЕДАКТИРОВАТЬ: В ответ на ваши комментарии:
Термин «репозиторий», в частности, относится к шаблону доступа к данным, который возвращает полностью заполненные коллекции (агрегаты) бизнес-объектов. Если вы обнаружите, что возвращение DTO является лучшим решением для вашей проблемы, тогда сделайте это, но вы можете запутать людей, если используете термин «хранилище» для ссылки на другие шаблоны доступа к данным. Лично я бы придерживался подхода к хранилищу и возвращал бы полностью заполненные бизнес-объекты, потому что я предпочитаю работать таким образом, но, как и во многих других случаях, это зависит от масштаба и сложности создаваемой системы.
Чтобы раскрыть логику ценообразования, вы, вероятно, просто хотите использовать метод, подобный следующему:
public class Product {
public decimal GetPriceFor(User user) {
// logic to determine per-user pricing goes here:
}
}