Most Read Latest News Blog Resources

Windows & .NET Watch: Add to cart? Maybe not




December 15, 2008 — 
If you are selling crocheted cell phone covers from your kitchen table, you can build your online store using a point-and-click solution from providers like Yahoo, Amazon or eBay. If you have a team of software developers sitting around idly after finishing their back-end business model, you’ll probably be inclined to build your e-commerce solution from scratch. If you’re anywhere in between, you might be tempted to investigate cart software.

Cart programs cost a few hundred to a few thousand dollars and provide a database schema and system data, lots and lots of dynamic pages in a tag-based development language (ASP.NET, PHP, ColdFusion, etc.), and some HTML/CSS skins for modifying the look of the site. Ease of installation is emphasized: Choose an installation directory, provide your database credentials and stand back. Once the generally massive installation scripts are done, you will have a public-facing store and an internal-facing administrative interface. From that stage, you’ll be able to get to “Hello, e-commerce” very quickly.

The allusion to the classic “Hello, World” program was intentional, since cart software should not be viewed as a stand-alone application but rather as a domain-specific language (DSL).

If you are in any way serious about your e-commerce solution, your store must encode some domain knowledge. If you sell chickens, your store has to know about eggs and feed; if you sell rocket engines, you have to know about heat and pressure. The encoding and expression of that domain knowledge are what will determine your Web store’s success.

The administrative interface to your cart software will not look very language-like. The “just fill out a few forms” look can fool you (or the predecessors whose work you have to refactor—the more likely scenario for SD Times readers) into defining your products in a haphazard manner. Almost all cart software allows you to create custom fields (such as nib weight or rocket-fuel compatibility) and generally makes it easy to add some “validation JavaScript” (i.e., business rules).

The behind-the-scenes upshot of this work is a set of attributes and the ranges of their acceptable values (the attributes and values of, say, a pen or a rocket part)—in short, a type definition. But instead of being stored in a text file in a human-readable format, as would be the case with a normal program, the definition is stored in the database. Further, you’ll have stored values for various instances of your types, and those, too, will be stored in the database (albeit with a dose of metaprogramming; the values will be in rows that have foreign keys to a table that defines the attributes).

The database of a cart site is not a relational model of the domain; rather, it is an opaque combination of system data relating to the cart itself, type definitions, the data that defines those types and the runtime-generated data of orders and statistics.

Confounding the task of working with cart software is that DSL interpretation (or page generation) is done in a tag-based language. That creates pages that combine presentation and domain logic. Worse (much worse), while the final HTML of such pages will be domain-specific (“medium pen nib”), the tag-based source code that generates that HTML will refer to the metastructure inside the database (lots of variables named “value” that are pulled from “columns” by “index” while looping on “rows”). Any nontrivial refactoring of presentation structure or page flow in cart software is difficult and error-prone, and can introduce significant performance overhead.

As you have likely gathered, I am not a fan. Designing a programming language, even a DSL, is tricky, and implementing a language is hard. Cart DSLs, while impressive as accomplishments, are at best comparable with 1960s-era mainframe languages. Pages recursively call themselves with “mode” values. State changes are performed with table-based lookup. The database conflates several concerns. None of that accomplishes the promise of delivering a system “without programming.” Just the opposite: Cart development is just programming in an overconfident language.

By all means, use a component or library to perform the functions of a Web shopping cart proper. Reinventing that particular wheel is a thankless task.

But don’t waste time and effort trying to avoid proper software development. If you are in the business of selling on the Web, you are in the software development business. The economical way forward is not avoiding that truth, but embracing it.

Larry O'Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.



Related Search Term(s): cartWeb programming


Share this link: http://www.sdtimes.com/link/33110
 

Comments

01/13/2009 07:04:43 AM EST

I don't get what you are advocating here. Are you for or against shopping cart software? Are you in favor of custom builds? Can you list examples? Probably not.

United StatesHugh


Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading



 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

4/12/2010 to 4/14/2010
Las Vegas
Penton Media

4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

4/19/2010
New York City
Flagg Management

4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG