Выполняют ли роли или представления внутри или вне шаблона хранилища?

Question

Является ли логика роли/представления внутри или за пределами шаблона хранилища?

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

Я хочу показать соответствующую цену соответствующему пользователю.

Если у меня есть хранилище этих продуктов, должен ли возвращаться бизнес-объект Product, содержать все 5 цен и как-то показывать только соответствующую цену?

Если да, то какой хороший образец использовать?

Должен ли я создать объект вида, который принимает бизнес-объект и роль и определяет правильную цену для показа? Или я должен поставить эту логику внутри бизнес-объекта?

(FYI: Я буду строить решение в ASP MVC, если вы думаете, что это поможет сформулировать ответ)

Answer 1

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

Этот подход также позволит вам протестировать вашу ценовую логику независимо от проблем с доступом к данным - например, используя «фиктивный» репозиторий, вручную создав продукт с пятью уже заполненными полями или используя mocking framework, чтобы высмеивать ваши вызовы репозитория. Перемещение такой логики вне ваших бизнес-объектов - например. поместив его в ваш уровень доступа к данным - может привести к анти-шаблону, известному как Anemic Domain Model.

EDIT: В ответ на ваш комментарий: «хранилище»

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

Выставить вашу ценовую логику, вы, вероятно, просто хотите использовать метод, как:

public class Product { 
    public decimal GetPriceFor(User user) { 
     // logic to determine per-user pricing goes here: 
    } 
} 

Answer 2

Один подход заключается в создании уровня услуг, который содержит бизнес-логику. Уровень сервиса взаимодействует с репозиторием, применяя любые необходимые вам правила или фильтры. Это означает, что все, возвращаемое с уровня сервиса, является просто обычным объектом C# (POCO).

Answer 3

После разработки некоторых продуктов с дополнительным уровнем доступа к данным я бы сказал: спроектируйте его с учетом функциональных зависимостей!

Предположим, у вас есть следующая очень распространенная структура словаря данных: productName, productDetail, productPrice, customerName, customerDetail.

Можно легко определить отношения: Клиент и Продукт.

класса клиентов: CUSTOMERNAME, customerDetail

Класс продукта: ProductName, ProductDetail

Но есть третье соотношение рисовать, это

класс CustomerProduct: CUSTOMERNAME, PRODUCTNAME, productPrize

Потому что вы можете рассуждать, что только имя_пользователя CustomerName XName | -> productPrize. Для использования случае Клиент C хочет знать цену продукта P:.

Клиента («C») приз («P»)

Приз метод должен быть делегированы знать точный приз и у вас есть четкое разделение проблем. Чтобы быть ясными в том, что точка: BO покажет no приз клиенту. Только метод имеет доступ к тонким данным. И этот доступ вы можете ограничить.