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 wanted 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 entitled Secure By Default.
Three-Way Data Access
Commerce Server provides a lot of functionality out of the box; in fact it provides not one, not two, but three disparate data access schemes. Talk about getting your money's worth :) What this translates to is two things: Blazingly fast performance and a high bar of entry for developers.
Basically each subsystem in Commerce Server comes with its own data access system which means that you as a developer will need to learn and master them all to be able to leverage the features provided by the product. There are some general traits to the various data access model: You won't have to do much SQL, if any.
The Profile system is our general purpose data access system that we use whenever we have a custom piece of data we need to store; user profiles, addresses, cities, etc.. You can think of the Profile system as half of an ORM, it will help you get your data into your application in a nice fashion without you having to do SQL which is nice but it doesn't provide the last part of an ORM, the O, the part that actually turns the data in objects. You could call the Profile system an RM because what it provides you a general purpose name value collection that you can build on top of. When everything is set up the profile system is quite nice to work with, sure the API is a bit primitive compared to a full fledged ORM but it certainly gets the job done and a couple of nice abstractions on top will get you a nice domain model to work with.
The Order- and Catalog systems are a different story in that they are very specific in their purpose; they only deal with specific domain objects: Order- and catalog objects.
I would point to the Catalog system as the very best part of Commerce Server, it feels complete and very well done, both feature-wise and data access-wise. There are no nasty XML files, no having to map multiple levels of abstractions before getting the job done, it all works and works beautifully. The Schema Manager tool is to Commerce Server Catalog system what Enterprise Manager was to SQL Server 2000: Your one stop place to setup schema for your database. Everything is handled in a graphical manner which is translated to SQL statements, procs, and physical tables. The Catalog system is set up for performance which is clear if you go ahead and poke around the database, tables are denormalized, physical objects are created for new catalogs, and so forth. Interestingly you can actually learn a lot from the performance database design by going through the various databases of Commerce Server.
Finally we've got the Order system where we have the third and final data access system and also the newest one in our happy little family. CS 2002 introduced XML mapping files to map orders, lines, payments to actual objects. In that respect we are actually dealing with a full ORM here, only it handles orders and various associated object but nothing else. You'll have to get your hands dirty with multiple XML files and you'll have to do manual updates to the database to get everything going. You won't however have to do anything to actually use the subsystem that's nice squirreled away in the API.
It's interesting to note that across all the data access schemes Commerce Server actually contains some very powerful APIs, if only they were combines and unified to provide the full flexibility to all the subsystems. As a developer you'll have to wrap you head around all the models; on the upshot of this the individual models are not that complicated to work with so it's not exactly a Herculean effort you need to put into learning the APIs: It's mostly a matter of knowing where to look. There are good reasons for the subsystems not being unified but I'd really like a single architect at Cactus to sit down and consider what needs to be done to leverage either a preexisting ORM or to unify the functionality found in the disparate DALs.
Developing with Microsoft Commerce Server 2007 Part 3: Testability