2010-04-25 5 views
2

Im utilisant les technologies ci-dessus et ont couru dans ce que je présume est un problème de conception que j'ai fait.SQL, MVC, Entity Framework

J'ai une table d'art dans ma base de données et j'ai été en mesure d'ajouter de l'art (je pense maintenant à ces produits numériques) à un panier + table CartLine bien. Le système que j'ai qui ajoute de l'art aux galeries et aux comptes d'utilisateurs, etc. fonctionne bien.

Maintenant que le client veut vendre des T-shirts, des tasses et des stylos etc., 'HardwareProducts', j'ai créé une table 'HardwareProducts'.

Maintenant, j'ai deux types de produits différents dans deux tables. J'utilise les GUID comme PK dans la table HardwareProducts et dans la table Artwork. Lorsqu'un client ajoute un article à son panier, je stocke le GUID dans la colonne ProductID de la table CartItems.

Le problème est que la base de données ne saura pas quelle table référencer lorsque j'apporterai l'objet LineItem à travers mon ORM à l'extrémité frontale. Dans OOP, je vois comment vous auriez une classe de base de produit, puis une classe DigitalProduct et une classe HardwareProduct, mais comment modélisez-vous cela dans SQL Server et Entity Framework, ou y a-t-il un autre façon?

EDIT:

C'est ce que j'ai dans une application de test à l'heure actuelle grâce aux commentaires ci-dessous. L'astuce qui l'a fait pour moi était d'utiliser le simulaire ORM à ce que Stéphane a souligné. Il m'a conduit à this excellent article.

alt text http://img411.imageshack.us/img411/3568/32654541.jpg

Permet:

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(); 

Je suis sur le point d'intégrer dans ma principale solution et vous permettra de savoir si j'ai plus les résultats, mais je pense tout semble bon . NB Il semble que la colonne Type qui a été mentionnée n'était pas réellement nécessaire à la fin, ce qui était une belle surprise grâce à la solution propre fournie par l'ORM. Thx tous

+0

scénario très intéressant. Je souhaite apprendre la solution aussi, donc si vous la trouvez s'il vous plaît poster :-). – Raja

+0

Ceci est une excellente information LukLed & Stephane. Je me suis rendu compte que ma demande de client avait introduit un problème de conception dans ma base de données (ce n'était jamais vraiment une base de données ecom, mais elle est en train de le devenir). Je fais quelques lectures de fond (sur Stephane et la cartographie) au moment où nous parlons pour étudier l'intégration de vos solutions et nous reviendrons vers vous une fois que j'ai mis en place un projet de test. – Anthony

+0

amusez-vous avec EF :) –

Répondre

1

Ceci est un scénario très cool pour montrer une fonctionnalité de EntityFramework!

Vous pouvez avoir un seul produit de table et une colonne de type qui définit le type de produit. Ensuite, dans votre Entity Data Model, vous définissez une entité de base Product, et vous créez 2 entités dérivées HardwareProduct et ArtProduct. Vous pouvez ajouter une condition sur la cartographie pour votre enfant entité comme ceci:

EDIT: Vous devriez lire Lorsque ProductTypeID = 1, mais je suis paresseux pour refaire la capture d'écran maintenant;)

inherited entity and condition http://i42.tinypic.com/2ibhqw3.png

Voir la "Quand ProductTypeID = 1"

:) Il

2

C'est une mauvaise conception de base de données. Vous devriez avoir sur la table de base avec ID et caractéristiques communes de chaque produit et tables d'extension avec des caractéristiques spécifiques pour différents types de produits.

Exemple:

produit: ID, Description, prix unitaire, ProductType (Création ou matériel)
Création: ProductID, Année, Taille
HardwareProduct: ProductID, d'autres caractéristiques.

Dans le panier, vous stockez ProductID et la quantité. Comme il peut y avoir plus de catégories de produits, vous devriez penser aux paramètres de stockage de table spécifiques à la catégorie de produit et à un autre tableau qui stocke ses valeurs.

Et un commentaire à votre solution POO. Avoir la classe DigitalProduct et HardwareProduct peut être intéressant au début, mais les éléments en magasin peuvent avoir tellement de fonctionnalités différentes, que vous ne pourrez pas le traduire en différentes classes.Le stylo a la couleur, le t-shirt a la taille, la tasse a la capacité, ainsi quand vous commencez à penser, il y a plus de différence entre la tasse et le T-shirt, alors entre l'illustration et le T-shirt. Alors, pourquoi la tasse est-elle au même endroit avec un t-shirt et une œuvre d'art ailleurs?

Vous devriez certainement regarder une solution de commerce électronique open source et regarder comment cela est fait là-bas. Votre client peut vouloir commencer à vendre d'autres types de produits et vous devez penser à concevoir une solution plus universelle. Ajouter d'autres classes ne sera pas efficace.

+1

d'accord, cela combiné avec un héritage dans le modèle de l'entité, et vous êtes bien :) –