Imagine this scenario: The year is 2003 and you're a Commerce Server developer who is setting out on the first Commerce Server 2002 and .NET project. Exited? You bet I was :) Way back we were asked to subcontract on a large ticket booking system developing the user profiling piece for the solution. With my background in OO naturally I wanted to go ahead a create business entities from the profiles in Commerce Server by inheriting them building entities specific to my needs.
Now you know what I ran into by trying to do that right? Pretty much a brick wall behind yet another brick brick wall. What I ran into was the fact that the Profile class is sealed and the brick wall behind it was the ProfileContext which is also sealed. Pretty much my idea was dead in the water at that point. So to return to the point of this post. Today several years after the fact it dawns on me that I have the perfect new tool to actually get some of what I wanted back then: Extension Methods.
As you probably know extension methods is a way of spot welding new functionality onto existing classes whether they are sealed or not. Basically a handy way of making external functionality available where you need it. Lots and lots of articles about extension methods have been written about the topic so suffice it to say that you put your extension methods in a particular namespace and to make them available on the target types you simply import them into your current context via a using or Imports statement depending on your particular language fetish :) With that out of the way lets skip right ahead to how you might use them in Commerce Server.
You can envision a scenario where you augment the profiles with specific functionality based on what you're doing. Say you're creating a product review profile in which you store the customer's opinion about a particular product. Use extension methods on that guy to include rendering a star rating, setting the customer review description, or administrative methods like approve/reject review.
For the product classes like ProductFamily, Category, etc. which are also sealed you could opt for something else entirely. From time to time we utilize the concept of search category, i.e. a category where the child categories and/or products are determined by a search criterion. Instead of putting this functionality in a helper somewhere you could go for a extension method to load the child objects of your current search category.
But why go for the individual entities themselves, why not go for the services published by Commerce Server like ProfileContext or CatalogContext to provide enhancements to the core functionality? I can certainly see some interesting scenarios enabled in the Marketing system, a subsystem which traditionally hasn't been very open to extensions.
To sum up extension methods is a brand new extension point for Commerce Server. Commerce Server has traditionally been very extendable but some areas are completely locked down. Until now that is. The scenarios I describe above is one way to do away with a lot of helpers floating around. Of course a much better way of accomplishing this is fashioning a facade layer on top of Commerce Server which will accommodate not only your custom logic but more importantly support your automated test suited (you do have one, don't you? :)). The facade layer will be the subject of a future post as I feel very strongly that architecturally this is a great thing to have in place to support you now and in the future.
Also let this post be a cry to the powers that be at Cactus to open up the APIs for inheritance. I certainly understand the need for sealing stuff especially with COM lurking under the covers but please, pretty please don't let that baggage spill over in future versions when COM is completely removed from the product. Finally sprinkle some interfaces on top and I'll promise to be a good boy from here on in :)
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.