A Tall Order: Three ASP.NET Shopping Carts - ' The Developer' (
Page 5 of 5 )
's View">
Customizing the Site
For the Web developer, the rationale in using a pre-packaged shopping cart is to minimize the amount of work that you, as a programmer, have to do. Generally, using a third-party product means less time spent debugging, assuming the third party products are well-tested themselves (which is the case with all three of these products). Thus, if you're building a site with very specific requirements, you probably want to find a kit that balances the least amount of work and configuration with the amount of flexibility you need.
ADVERTISEMENT
DotNetCart has excellent documentation, divided into two portions: Developer documentation and User documentation. The developer documentation provides the classes, methods, properties, and events available to the programmer. Using this documentation and the precompiled DLL that ships with the product, you can, if you want, completely forgo the somewhat minimalist GUI example and build your own from scratch.
The developer documentation outlines three main items and a slew of other items, including a class called Cart, web controls called DisplayCart and DisplayCatalog, and several web controls for specialized tasks (such as PaymentSetting, ShippingSetting, TaxAdmin, MostPopularItems, and RelatedItems). Although the documentation is excellent, some of these classes do lack general descriptions; that's one area that could easily be improved.
Let me give you a taste of the process, which is simpler than my general description may make it seem. Since several of these items are web controls, I could right-click in the Toolbox window of Visual Web Developer, choose Choose Items... and open the Choose Toolbox Items dialog box. Adding the dotnetCART.dll file presented me with a new set of custom controls in my toolbox, ready for use. I created a new form, and dragged a couple of the controls onto it just to see how it worked. As expected, I got a nice list of all the properties in the Properties window. When I switched to the Source view, the control was there, ready for me to work with:
When you purchase AspDotNetStorefront, you get full source code. That means you can have at it, making changes as you see fit; or, you can build your own system from the ground up, using the rich set of classes available. The package includes many classes (a PDF chart on the company's web site lists them all).
One particularly interesting aspect of AspDotNetStorefront is its proprietary technology called XmlPackages, whereby you can describe your entire product catalog using XML. The system then uses XSL transforms to render the data as needed. For example, you can provide an overview, feature list, and specification set in your HTML for a particular product. Then you can easily create a product detail page that includes three tabs, on for the overview, one for the feature list, and one for the product specifications.
CommerceStarterKit is similar to AspDotNetStorefront in that it's a prepackaged site ready for use. It provides several classes, include Order, Product, Shopping Cart, and ShoppingCartItem. Further, since you get full source code, you're free to modify it as you wish. The only catch is, from looking at the source code, it's clear that instead of CommerceStarterKit providing you with an existing API from which you can build your own site, you're more likely going to be modifying the existing code. The system is built modularly, but it's not intended as a reusable API in the way that the other two products are.
Unfortunately CommerceStarterKit has one glaring weakness: it doesn't work well in the FireFox web browser. Considering FireFox's growing popularity, that's not a minor issue.
Support for both DotNetCart and AspDotNetStorefront was excellent, overall. The windows help file documentation for AspDotNetStorefront does suffer a bit, but the company tells me they are working on documentation improvements.
CommerceStarterKit, on the other hand, is of a different breed. This is an open source package, and so you have to take into consideration the approach of the open source community. Support is through forums, with everybody joining in. In fact, the web site is primarily set up as a community, making it hard to find even the most basic of information. For example, the other two products had nice product feature matrices; I could not find one for CommerceStarterKit. I also had trouble finding a definitive list of databases the product has built-in support for.
Making the Sale
All three products have merit, and I'm personally happy with all of them. Each has its place, depending on your needs. However, you can use only one — at least, only one per ASP.NET site. Which would I go with? The answer depends on the requirements of the site. Here's how I would make the decision.
If you have a short time limit and need the site up and running as quickly as possible: theres's no question, go with AspDotNetStorefront. You can effectively have an entire online store set up instantly with this kit, and the site is easy to modify. This is definitely my personal favorite.
If you have a lot of time and want to do a great deal of programmatic customizations, and you want to have your hand in the code quite a bit, choose CommerceStarterKit. Well, I might also go with AspDotNetStorefront; both are great for this purpose.
If you're building a site from scratch, in which you know you'll have to do a lot of customization, and you need a kit to supply the basics, then I'd go with DotNetCart. Although it doesn't offer nearly as much of a full-featured drop-in GUI as do the other two, I usually don't want a full-featured site. I prefer components, and DotNetCart gives me the components I need. The moral is: Don't let the minimal samples fool you. This product is packed with programmatic features.