We started by developing a solid framework - FrameWorx is an extensible platform with its first incarnation as AuctionWorx Enterprise.
The Accounting Service handles all invoicing and payment transactions of site fees and third-party sales. Site fees are any fees that are triggered by the event system, typically when a seller utilizes features of the site such as listing items. Third-party sales are the buy/sell agreement between a seller and the eventual winner of a listing (highest bidder of an auction, purchaser(s) of a fixed price listing, etc).
The Accounting Service supports a Fee provider model which allows developers to assess fees based on events and listing state.
The Account Service supports a Payment provider model which allows payments to be made either synchronously, as in the case of Authorize.Net; or asynchronously, as in the case of PayPal. The provider model allows additional payment providers to be implemented and integrated into the platform.
The Common Service handles many of the commonly used components of AuctionWorx such as the Custom Field system, and the hierarchical Category system.
The Listing Service handles the workflow of creating, editing, and resolving listings in addition to buyer initiated events (bids).
The Listing Service supports a Listing Type provider model which allows additional listing types to be defined. The software includes Standard Auctions, Fixed Price listings and Classifieds.
The Site Service supports the presentation layer and administrative interface.
The Notification Service handles all outgoing emails from the site asynchronously so as not to impact performance.
The Scheduler Service triggers listing starts and resolutions.
The User Service provides user and account services.
In this mode, the BLL and the DAL execute within the IIS worker process context which includes the Scheduler and Notifier, in addition to the front-end MVC. MVC communicates with the BLL via client classes with In-Process access to the BLL Services. The BLL communicates with the DAL In-Process. This is most useful in environments where the installation needs to be kept simple, or where multiple AuctionWorx sites could be executing on the same IIS webserver.
Both the BLL and DAL execute within a Windows Service which includes the Scheduler. There is an additional Windows Service for Notifications since there is such a clear demarcation between other BLL services, and Notification fulfillment. Additionally, Notification can be setup to be run on a more appropriate server. MVC still executes within the IIS worker process context and communicates with the BLL via client classes with Windows Communication Foundation (WCF) service remoting to the BLL/DAL Windows Service.
Deploying to the Azure Cloud with full support for Azure SQL, Service Bus, Blob Storage, and Azure Web App Service.
The source to the MVC project, views, and controller code is included. This will allow a developer to change any aspect of the presentation layer. The remaining functionality can be extended by implementing providers and making calls to the API. The BLL and DAL are available only as compiled runtime binaries however the source to these are not necessary to implement any required changes.
The MVC project source is included: controller code (presentation logic), web pages (RAZOR), web partials (RAZOR), and any related HTML resources can be modified. All MVC related source code is commented and documented.
View code exists to actually present the data (model) to the user. There usually isn’t much logic in View code, except logic pertaining to presentation, such as looping through collections, etc.
Controller code exists to prepare the data (model) for presentation by the View. Therefore, calls to the client are usually made in the Controller code. Changes that involve modification to the data about to be displayed or the form data entered can be made here.
These static HTML assets are used by Views and can be modified as desired.
The provider model design pattern allows specific functional areas to be implemented and integrated into the platform using a dependency injection container (Microsoft Unity). As such, developers can implement additional or replacement providers to the following functional areas:
The Listing Format Provider allows you to define your own listing formats. Standard Auction, Fixed Price and Classifieds are all included with the software.
For example, if you wanted to implement a Dutch or a Reverse Auction, you would implement your own Listing Format Provider that contains the necessary business logic.
The Fee Provider allows you to assess fees, based on events and the listing state. The Fee Provider is queried any time a listing is created, updated, closed, etc… to calculate site fees.
For example, you may want to implement your own Fee provider if you have special cases where certain users should receive discounts or an existing database is queried.
The Payment Provider allows you to implement payment methods to be made either synchronously, as in the case of Authorize.Net; or asynchronously, as in the case of PayPal.
For example, you may want to implement Google Checkout and offer that as a payment option to your users.that authenticates users against your existing user data.
The Media Asset Provider allows you to define new types of media that can be included in Listings and Listing Actions (Bids, Purchases, etc…). The system provides interfaces for generating, storing, and referencing media.
For example, you may want to implement saving and storing listing images with a specific image hosting service.
The Invoice Logic Provider provides access to shipping, tax, and subtotal calculations.
For example, you can add a custom invoice property or designate special considerations for when taxes are calculated.