制作我们自己的Ebay(拍卖系统EN) - Considerations -

March 25,2004

Considerations - Page 8

Chris Payne

September 11, 2000

So now you've got yourself a pretty functional auction. Let's talk a bit about what we haven't covered,
and a few miscellaneous things.

Things to Add

While this auction will work, it lacks a few features of finer products. For instance, you could have
built in a "take less" option - if, for example, a user bids for 10 items, but is willing to take less if
necessary, then this could be accommodated. It would require adding a boolean field to the database, and a
few modifications to the ResolveBids() code. You should also give the seller the option to "not take
less," meaning that if all the items haven't been bid for, then the whole thing is off.

Another option could be adding "deeper lots." This allows sellers to specify that they have multiple lots
that they must sell together - for instance, 5 TV's and 5 VCR's. These could all go in one lot, but by
separating them into multiple lots that are sold together, you are offering the seller and buyers an
advantage (both pricewise and competiveness-wise).

Most auctions also allow "reserve prices." This is a price the seller specifies that must be met before
any items can be sold. For example, I want to sell a car, but I won't take less than $5000. This is a bit
different than the minimum acceptable bid, in that the latter is set low to encourage buyers to place
bids, while the former ensures I don't end up selling my $5000 car for $2 - seller protection.

A fully functional auction should also have more robust alerting mechanisms. I haven't built in here the
ability to notify users when they have been outbid. (Make sure though, that if you do build this
functionality, you don't send an alert every time the proxy engine places a bid - the user would get
flooded with tons of emails that aren't necessary. Rather, just send an alert when the price for an item
grows larger than the maximum bid the buyer specified, to give them another chance at the item.)

Finally, you'll need more functionality than just the functions I specified here. You might want to create
an admin interface that allows an adminstrator to view all bids, users, and auctions, delete specified
items, modify them, etc. And you'll need to build the visual front end - something so that buyers and
sellers can bid for and enter items to sell, and view the current status of an auction (the current
winning bid, the number of items sold, etc). You may also wish to "beef up" the tables specified here, to
allow users to enter in more specific information (i.e. a SKU number, a URL, etc).

Coding Practices

You may have noticed I specified the connection string and created a recordset object in every function.
While this was done for clarity in this article, a more efficient method would be to specify a global or
session variable somewhere else - for instance in the global.asa file, or an include file that is included
on every single page.

Also, this type of functionality would best be wrapped up in a COM object. This would enhance speed and
increase security. Do all the testing in the ASP first though!