views:

84

answers:

2

I'm building a content-managed site with a homegrown API built by several developers I work with. The API is just a nice LINQ-like ORM-like layer between the Sitecore CMS (our CMS in this case) and our C# code to bind data items to controls. I've found in several places I've had the opportunity to to decide between creating methods and properties to retrieve "sub items" to get data.

For the purpose of explaining Sitecore terms, assume the word "template" means a custom class representing some sort of Sitecore type.

// retrieve all children of the Sitecore template "Content Folder" below the PageData section
// assume PageData is an object that represents that section in the Sitecore content tree
public List<ContentFolder> GetContentFolders() {
  return PageData.CurrentItem.ChildrenByTemplate("Content Folder").As(i => new ContentFolder(i));
}

The above code will do some LINQ on the PageData section to get a list of sub-items of the type "Content Folder". Note: the .As() is just an extension method to make this easy to make a list of that type. In this example, its obviously a method. However, should it be a public property instead? E.g.

public List<ContentFolder> ContentFolders {
  get {
    return PageData.CurrentItem.ChildrenByTemplate("Content Folder").As(i => new ContentFolder(i));
  }
}

Which is more appropriate? Are they equal? I've definitely found a clear example of when a method would make more sense: any case in which I need to pass it parameters or where I can overload the parameters. E.g.

public List<SupportProductItem> GetSupportProductItems() {
  return GetSupportProductItems(true);
}

public List<SupportProductItem> GetSupportProductItems(bool excludeUnsetProducts) {
  var productItems = CurrentItem.ChildrenByTemplate("Support Product Item").As(i => new SupportProductItem(i));

  if(excludeUnsetProducts)
    productItems = productItems.Where(i => i.ProductSelector.IsSet).ToList();

  return productItems;
}

A case where I have chosen a property over a method (in my opinion) is when I'm just checking something simple instead of retrieving lists of data, e.g.

public bool IsSet {
  get {
    return (CurrentItem != null);
  }
}

Instead of:

public bool IsSet() {
  return (CurrentItem != null);
}

So in code that would look like:

...
if(ContentFolder.CurrentItem.IsSet) {
  // code
}
...

Are there any other things to consider other than overloading and personal preference when deciding between using a method vs a property? Anything "technical" I should consider?

+4  A: 

The normal Properties vs. Methods guidelines apply.

David Neale
Thanks. This is a great list! One of the lines says "Properties that return arrays can be very misleading." Does that includes generic lists as well like arrays?
Mark Ursino
No, collections are fine to return. There's another good article on MSDN about that here: http://msdn.microsoft.com/en-us/library/0fss9skc%28VS.80%29.aspx
David Neale
+2  A: 

I'm sure that this has come up before, but basically a Property is expected to be:

a) relatively quick
b) have no side effects

So if your query takes a significant amount of time you should consider putting it in a method. Otherwise, a property is just fine.

ChrisF