This project is read-only.

Field vs Part Fitler Query performance and ease of use comparison

Topics: General
Aug 3, 2012 at 3:13 PM

We're starting a project at the moment using Orchard and we're having a dilemma about wether we should use a Field or a Part. We've come up with a dummy example to illustrate the situation:

  1. Assume we have a Fruit Content Type
  2. Assume we have a Fruit Color Content Type 
  3. We want to create a many to 1 relationship between our Fruit Content Type and Fruit Color Content Type where each Fruit is associated with one Fruit Color. We will later want to filter our Fruits by their Fruit Color in order to display all red fruits, all orange fruits, etc...

Question: Would we be better off...

  1. creating a FruitColorPicker Field Type (probably based on the "Content Item Picker" Field Type but specialized for FruitColor Content Items) then add a FruitColorPicker Field to our Fruit Content Item
  2. creating a FruitColorValue Part containing a "FruitColorId" property that contains the Id of an existing FruitColor
Aug 3, 2012 at 5:20 PM

Wouldn't you need a FruitColorPicker in both cases? In any case, using a field seems as easy as adding a part. However, for this particluar example, I'd say go with Taxonomies: create a Fruit Color taxonomy and attach a Taxonomy field to your Fruit Content Type. Done.

Aug 3, 2012 at 6:26 PM

I reckon our dummy example seems a bit simplistic considering the question I'm asking :P 

I think the Taxonomy approach is a very good one (you're talking about Contrib.Taxonomy right?). 

Assuming we have a page where users select a Color from a list, we could then use TaxonomyService.GetContentItemsQuery(TermPart, null) to retrieve all Content Items with the given color. 

My biggest concern is, performance wise, does anyone know if there a big difference between:

TaxonomyService.GetContentItemsQuery(OrangeTermPart, null)


ContentManager.Query("Fruit").Where<FruitColorValuePartRecord>(fc => fc.Id == OrangeColorId)


Aug 3, 2012 at 8:27 PM
spoissant wrote:

I think the Taxonomy approach is a very good one (you're talking about Contrib.Taxonomy right?). 

Yeah, that's the one.

Regarding performance, I honestly wouldn't know. Perhaps generate a few thousand versions of each, and perform a few thousands queries on each set?