Как бы вы закодировали шаблон хранилища, как «заводской» шаблон дизайна?

Question

Я думал, что переписал бы этот вопрос (та же итерация). Оригинал заключался в том, как обернуть шаблон репозитория вокруг базы данных EAV/CR. Я пробую другой подход.

Вопрос: Как вы могли закодировать хранилище данных в виде шаблона «заводской»? У меня есть фиксированное количество сущностей, но атрибуты для этих объектов довольно специфичны для клиента. Они рекламируют продукты, которые все одинаковы, но каждый клиент придает им различную информацию на основе своей бизнес-модели. Например, некоторая забота о проценте сляба от отходов, в то время как другие заботятся о количестве проданных фунтов. Каждый раз, когда мы находим другого клиента, мы добавляем кучу полей, удаляем кучу полей, а затем тратим часы на то, чтобы каждое решение было актуальным до последней общей версии.

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

Предыдущее содержание вопрос:

Мы имеем/модель данных CR EAV, что позволяет различные классы для одной и той же сущности. Это отслеживает продукты, в которых клиенты имеют совершенно разные продукты. Клиенты могут определить «класс» продукта, загрузить его с полями, а затем заполнить его данными. Например,

Product.Text_Fields.Name
Product.Text_Fields.VitaminEContent

Любое предложение о том, чтобы обернуть шаблон репозитория вокруг этого?

У нас есть три таблицы EAV: таблица продуктов, таблица значений и мета-таблица, в которой перечислены имена полей и типы данных (мы перечисляем типы данных, потому что у нас есть другие таблицы, такие как Product.Price и Product.Price Мета-данные, а также другие, такие как Product.Photo.) Клиенты отслеживают все виды цен, например, процентные различия между конкурентами и расчеты на лету.

В настоящее время мы используем Linq to SQL с C#.

Edit:

Мне нравится "Dynamic Query" Linq ниже. Идея нашей БД похожа на хранилище раздевалок для раздевалок. Каждый спортсмен (или клиент) организует свой шкафчик по своему желанию, и мы обрабатываем его хранение для них. Нам все равно, что в шкафчике, пока они могут делать то, что им нужно.

Очень интересно ... Объекты, переданные в репозиторий, могут быть динамическими? Это почти имеет смысл, почти как фабричный шаблон. Возможно ли, чтобы клиент разместил свои собственные определения классов в текстовом файле, затем мы наследуем их и храним их в БД?

Answer 1

Как я понимаю, шаблон репозитория абстрагирует физическую реализацию базы данных из приложения. Планируете ли вы хранить данные в разных хранилищах данных? Если вы довольны Linq для SQL, то я бы предположил, что вам не нужно абстрагироваться таким образом, поскольку это выглядит чрезвычайно сложным. Тем не менее, я вижу, что предоставление репозитория в стиле EAV, т. Е. Запрос должен быть передан Таблица, Тип поля и Имя поля вместе с любым условным требованием, может предложить вам абстракцию, которую вы ищете.

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

Возможно, вы захотите взглянуть на расширения Dynamic Linq, найденные в динамическом предварительном просмотре данных на Codeplex.