SQL, MVC, Entity Framework - PullRequest
Новая
       22

SQL, MVC, Entity Framework

2 голосов
/ 25 апреля 2010

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

У меня есть таблица Artwork в моей БД, и я смог добавить искусство (теперь я думаю о них как о Цифровых продуктах) в корзину покупок + таблица CartLine. У меня есть система, которая добавляет искусство в галереи, учетные записи пользователей и т. Д. Отлично работает.

Теперь клиент хочет продать футболки, кружки, ручки и т. Д. «HardwareProducts», поэтому я создал таблицу «HardwareProducts».

Теперь у меня есть два разных типа продуктов в двух таблицах. Я использую GUID в качестве PK в таблице HardwareProducts и Artwork. Когда покупатель добавляет товар в свою корзину, я сохраняю GUID в столбце ProductID в таблице CartItems.

Проблема в том, что база данных не будет знать, на какую таблицу ссылаться, когда я перенесу объект LineItem через мой ORM во внешний интерфейс.

В ООП я вижу, как у вас будет базовый класс Product, а затем класс DigitalProduct и класс HardwareProduct, но как вам смоделировать это в SQL Server и Entity Framework, или есть другой способ?

EDIT:

Это то, что у меня есть в тестовом приложении на данный момент, благодаря комментариям ниже. Уловка, которая сделала это для меня, заключалась в использовании симуляции ORM к тому, на что указывал Стефан. Это привело меня к этой превосходной статье.

альтернативный текст http://img411.imageshack.us/img411/3568/32654541.jpg

Позволяет: 

int prodCount = _entities.Product.OfType<ArtWork>().Count();
IEnumerable<LineItem> lineItem = _entities.LineItem.Include("Product");
int artWorkCount = lineItem.Select(p => p.Product).OfType<ArtWork>().Count();

ArtWork prod = new ArtWork();
            prod.Price = 2;
            prod.ProductName = "atlast";
            prod.Downloads = 3;
            prod.GalleryID = 1;
            _entities.AddToProduct(prod);
            _entities.SaveChanges();

Я собираюсь интегрировать его в свое основное решение и сообщу вам, если у меня появятся какие-либо результаты, но я думаю, все выглядит хорошо. NB. Похоже, что столбец Type, о котором упоминалось, на самом деле не был нужен в конце, что стало приятным сюрпризом благодаря чистому решению, предоставленному ORM. Спасибо всем

Ответы [ 2 ]

2 голосов
/ 25 апреля 2010

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

Пример:

Продукт: ID, описание, UnitPrice, ProductType (художественное или аппаратное обеспечение)
Работа: ProductID, Год, Размер
HardwareProduct: ProductID, другие функции.

В корзине вы храните ProductID и количество.

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

И комментарий к вашему решению ООП. Поначалу классы DigitalProduct и HardwareProduct могут быть интересны, но предметы в магазине могут иметь так много разных функций, что вы не сможете перевести их в разные классы. Ручка имеет цвет, футболка имеет размер, кружка имеет емкость, поэтому, когда вы начинаете думать, между кружкой и футболкой больше различий, чем между рисунком и футболкой. Так почему же кружка в одном месте с футболкой и рисунком где-то еще?

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

1 голос
/ 25 апреля 2010

Это очень крутой сценарий, чтобы показать одну особенность EntityFramework!

У вас может быть один табличный продукт и столбец типа, который определяет тип продукта. Затем в своей модели данных сущностей вы определяете базовую сущность Product и создаете 2 производных сущности HardwareProduct и ArtProduct. Вы можете добавить условие в сопоставление для вашего дочернего объекта следующим образом:

РЕДАКТИРОВАТЬ: Вы должны прочитать Когда ProductTypeID = 1 , но мне лень сейчас повторить скриншот;)

унаследованная сущность и состояние http://i42.tinypic.com/2ibhqw3.png

См. «Когда ProductTypeID = 1»

Там:)

...