Принадлежат ли роли / представления внутри или вне шаблона репозитория? - PullRequest
2 голосов
/ 01 марта 2009

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

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

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

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

Если да, то какой шаблон лучше использовать?

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

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

Ответы [ 3 ]

3 голосов
/ 01 марта 2009

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

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

РЕДАКТИРОВАТЬ: В ответ на ваши комментарии:

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

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

public class Product {
    public decimal GetPriceFor(User user) {
        // logic to determine per-user pricing goes here:
    } 
}
2 голосов
/ 01 марта 2009

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

0 голосов
/ 01 марта 2009

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

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

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

класс Заказчик: customerName, customerDetail

класс Продукт: productName, productDetail

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

Класс CustomerПродукт: customerName, productName, productPrize

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

Клиент ( 'C'). Приз ( 'P')

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

...