Kick off

The “E-Commerce Catalog” is a Web Client Software Factory 2.0 application intended to:
  • Show recommended practices in incremental Web development.
  • Demonstrate how a WC-SF project can be faced and developed.
  • Demonstrate how Web Client Software Factory 2.0 assets help to solve common technical challenges.

The E-Commerce Catalog allows registered users to search items for sale. The application lets users:
  1. Place items in a virtual cart.
  2. Select the payment method and billing/shipping address for the order.
  3. Confirm the order.

The E-Commerce Catalog consists of two Web sites:
  • Public Web site: this Web site is accessed by customers to make purchases.
  • Admin Web site: this Web site is accessed by administrators to manage the products catalog. An administrator can add and edit products, categories, prices, shipping and payment settings, etc..

This post is the first one of a series of posts. In this post you will find:
  • How the application was designed incrementally.
  • The first steps.
  • The rationale behind our technical decisions and implementations.

First Things First

First of all, we needed a general design for the solution. We started with:
  1. Defining drafts for the pages the application would have.
  2. Making a quick list of the business entities involved in the application.
  3. Deciding what modules would the application have. Figure 1 illustrates the modules that the application will contain.

ECommerce Catalog - Application modules.png
Fig. 1 | Application modules

Decisions Taken

Before starting with the application development, we made the following decisions:
  • We would use Test Driven Development. This would be fairly possible because:
    • The Model-View-Presenter (M-V-P) pattern described in Web Client Software Factory facilitates code testing, and recipes automate the generation of views with presenters.
    • The guidance package generates test projects for modules that include mock classes and sample tests.
  • We would store all the data in memory instead of using a database to persist the data. This would allow us to be more focused on the application logic development.

Technical Challenges

The following table describes the technical challenges that the E-Commerce Catalog application addresses:

Technical challenge Description How is this demonstrated in the E-Commerce Catalog?
Modularity Ability to build complex sites based on modules that can be independently developed, tested, versioned, and deployed. > Web site solution structure. > Admin, Products, and User business modules that use the Composite Web Application Block. > CatalogData foundational module that use the Composite Web Application Block. > Distributed Web.config files. > Use of the services and the dependency injection pattern to enable loosely coupling of components
Layout management Ability to create a common user experience across different independent modules, separating the responsibility of the UI design from the UI development. > Application uses master pages for public site and for module Web pages. > Ajax enabled Web site. > UI design and UI logic separation through the Model-View-Presenter pattern in Web pages, master pages, and user controls. > Use of ASP.NET themes and skins. > Use of a site map provider to display module actions on the Web site.
Navigation and page flow Ability to design and implement transitions between Web pages and separate navigation logic from business logic. > The Admin and User modules implement a page flow using the Page Flow Application Block.
Unit testing Web solutions Ability to run unit tests against Web page logic. > All views in the E-Commerce Catalog use the Model-View-Presenter pattern to isolate the UI logic to increase the testing surface. > Services and controllers where developed using TDD. > All modules include unit test projects.
User profile based UIs Ability to change the behavior of the UI based on the user identity and profile information. > Web site configured with two roles, Administrators and Operators. > Actions available in each module operate on different permissions sets for the available roles (for example, the Administrator role can view the site configuration, but the Operator role cannot view it). > Use the site map provider to display permission aware actions on the Web site. > Rule-based permissions using the Enterprise Library Security Application Block defined in configuration files.
Authentication Ability to identify registered users of a site. > Forms authentication for all protected pages. > Views are protected with settings in the modules Web.config files that denies access to anonymous users. > Application uses a custom Membership Provider (XmlMembershipProvider)
Authorization Ability to change permissions for different users. > Each module operates with different permissions sets. > Application uses ASP.NET role manager. > Application uses a custom Role Provider (XmlRoleProvider)
Securing data Secure user and site information. > All exceptions are shielded using Enterprise Library and ASP.NET configuration to prevent information to be leaked to end users in the event of a runtime exception. > User input is validated for type, length, format, and range. > By using the Composite Web Application Block, untrusted content is encoded before displaying it on a browser.
System availability and scaling Maximize uptime and minimize the time to diagnose problems. > Logging exceptions using the Enterprise Library Logging Application Block for simplified management and diagnostics.
Easy deployment Minimizing the complexity to deploy new or updated functionality on a site. > XCopy deployment of modules. > Modules are deployed independently of each other. > Distributed Web.config files minimize configuration contention.


You can see the spanish version here.

Last edited Aug 6, 2008 at 2:46 PM by mconverti, version 5

Comments

No comments yet.