A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really want to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.
Check out part 1 Secure By Default where I discuss the security aspects of Commerce Server, part 2 Three-way Data Access in which I write about the various ways of getting data into your applications, and part 3 Testability which not surprisingly is all about how CS lends itself to unit testing.
One of the first things I noticed when I started working with Commerce Server a number of years back was the extensive use of "magic strings" to access various custom properties of data objects. In fact the use of magic strings was pervasive across the entire product from the catalog system over the profile and orders system to the marketing system. With the current version (2007) that changed for the better with regards to the order system but still holds true for the other subsystems.
Magic strings of course is a term which describes the use of a string to identify a particular element in structures like arrays, dictionaries, and the like; an example would be myArray["myMagicString"].
The reason behind the use of magic strings is that each of the individual subsystems of Commerce Server offers a great deal of flexibility including the ability to define your own schemas for almost everything. This means that the actual structure of say an profile is known only at runtime. Employing magic strings is a nice and easy way of getting the job done but it does leave a lot to be desired when developing with the product.
One of my pet peeves is explorability; by explorability I mean the ability to use intellisense to get an idea of what you've got at your disposal on any given API. Commerce Server allows for this for the most part but when it comes to catalog objects and profiles sadly this is not the case which leaves you referencing other tools to look up the magic strings for accessing a particular property on an object. Not exactly a productivity booster. Of course the remedy is fairly straightforward: You simply build an abstraction layer on top of the weakly typed objects and work off of that instead. This does produce more code that we need to maintain ourselves and with that an increased cost to our customers. Alternatively you could go low budget and maintain a library of magic strings in a central class or even combine that with the abstraction layer.
Interestingly the orders system allows for strongly typed properties. As I wrote in part 2 Three-way Data Access the order system is an ORM in its own right which provides strongly typed properties on the object, all that is require is a little mapping via XML. With that in mind it seems strange that we have to create our own abstraction layers on top of the other subsystems.
The use of of using magic strings means that we end up with runtime errors instead of compile time errors because we can't rely on the compiler to check the validity of magic strings. Refactoring rapidly becomes more difficult at this point leading me to a second pet peeve of mine: Catching errors as early as possible. I really like me to be the first one to know about any errors in the code I write, especially when they're as trivial as misspelling a magic string.
Now one could argue that ORM isn't practical on top of the catalog system due to the very extensible nature of it. It's intended to be expanded by business users, a tool is even provided to enable them to do so making mapping of the catalog object less feasible. The problem however is that with most Commerce Server solutions you'd need a developer to actually use the newly added product definitions and fields for something, e.g. displaying them in the UI, leveraging them in the pipeline system, etc.. This leaves us with the original problem: Developer productivity.
From my point of view there's a single solution available to us: Code generation. To effectively work with the subsystems in a consistent and effective manner code generation could be employed but it requires some heavy lifting as you'd have to create specialized generators for the individual subsystems. The good news is that meta data is indeed available to allow for the process.
One might argue that a second option is available; namely to rewrite the data access schemes of the profile- and catalog system to more closely match that of the order system in order to leverage ORM principles. That however remains closed to anyone but the developers at Cactus Commerce.
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.