Stock Trader V2 Reference Implementation

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The latest Enterprise Library information can be found at the Enterprise Library site.

On this page:
Limitations | The Scenario | Problems with the Old Stock Trader | Stock Trader V2 Overview - Overview of Your Account Position, Analyze Market Trends, Read Relevant News Articles, Place Orders to Buy Or Sell Stock, Editing Current Account Holder Information, Guidance Module, Capture Diagnostic Information | Stock Trader V2 Architecture | Modular Development

The Enterprise Library 5.0 Silverlight Integration Pack ships with an example application, called Stock Trader V2, that demonstrates how you can apply Enterprise Library to a Microsoft® Silverlight® application. This application addresses some real-world challenges that developers face every day when building complex applications.

The Stock Trader V2 reference implementation may look familiar to you. We have based it on the Stock Trader reference implementation from another patterns & practices project, Prism.

Sharon Says:

Prism provides guidance designed to help you more easily design and build rich, flexible, and easy-to-maintain Microsoft Windows® Presentation Foundation (WPF) desktop applications and Silverlight rich Internet applications (RIAs) and Windows Phone 7™ applications. Using design patterns that embody important architectural design principles, such as separation of concerns and loose coupling, Prism helps you design and build applications using loosely coupled components that can evolve independently but which can be easily and seamlessly integrated into the overall application. Such applications are often referred to as composite applications.</td>

Limitations

The goal of Stock Trader V2 is to show techniques for applying Enterprise Library in various scenarios.

Stock Trader V2 is not meant to be a fully working implementation of a Stock Trading application. For example, while the Stock Trader uses web services and a database for certain situations, it also uses randomly generated data for other scenarios. You should view the Stock Trader V2 as a demonstration of how you can apply Enterprise Library to solve a number of common development challenges.

The Scenario

The company, Woodgrove Bank, has always been a big player in the stock trading software market. Over the last decade, they have grown to become a market leader with their stock trading application Stock Trader, affectionately called "The Old Stock Trader." Several thousand stock traders use this application daily, and together they trade more than $10 million in stocks every few hours.

Problems with the Old Stock Trader

While the old Stock Trader is still quite competitive with regards to its functionality, it’s definitely showing its age:

• It was built as an ASP.NET 1.0 web application and didn’t use any modern techniques for providing a great user experience such as AJAX, jQuery or Silverlight, and users were complaining about its usability and performance.
• It was not built to be very maintainable. One issue was the tight coupling of its components. Adding new features or changing existing logic was always challenging and often introduced more problems.
• It didn’t provide much helpful diagnostic information. Diagnostic logging was only added here and there as an afterthought. Typically the only way problems with the application were detected was when angry users would notify the support team.
• The parts of the Old Stock Trader that allowed a user to edit his account holder information and to place orders had many problems. The validation logic was spread throughout the application and was riddled with duplicate code.

Because of these problems, about two years ago efforts to improve the old Stock Trader began. The following areas were improved:

• Enterprise Library was applied to help with exception handling and diagnostic logging and tracing. Exceptions were written to the Windows Event Log. There was not enough time to implement this everywhere, but at least the most critical areas would now report problems in a structured way.
• A couple of years ago, Woodgrove Bank began to use System Center Operations Manager (SCOM) to monitor the health of its applications. Now that the old Stock Trader also produced diagnostic information, SCOM could also be used to monitor its health.
• The logic that allowed a user to edit his account holder information was completely rewritten to use the ADO.NET Entity Framework and the Validation Application Block. There was not enough money in the budget to rewrite the order processing functionality as well, so this remained largely unchanged.

Stock Trader V2 Overview

While the improvements did much to increase the stability, manageability, and performance of the Stock Trader, the user experience still didn’t meet the end users' expectations. For that reason, last year the management of Woodgrove Bank decided to build a new version of the Stock Trader, using Silverlight as a front end. It was very important to Woodgrove Bank's management that the investments that have been made to improve the old Stock Trader would not be wasted, therefore diagnostic logging and tracing for the new Stock Trader should build upon the foundation that was laid by the old Stock Trader, and the data model and validation rules for the account holder module would have to be reused as much as possible.

Stock Trader V2 also needed a new and fresh appearance and feel. This is what the new stock trader looks like:

In this section, we’ll provide an overview of the new Stock Trader V2 application.

Note

Each module has a theme that maps to a particular aspect of Enterprise Library. For example, the position module focuses on caching and the Account Holder Info Module focuses on validation in combination with Windows Communication Foundation (WCF) Data Services. The exception to this is Exception Handling and Logging, which are implemented everywhere in the application.

Overview of Your Account Position

When the Stock Trader reference implementation starts, users will first see the account position summary screen. Here they can get an overview of all the stocks they currently own, and see their cost basis and current market value.

To improve startup performance, the account position screen will cache the current account position to isolated storage. Therefore, the data is also available, even if you restart the application. The account position will expire at the end of the day. To refresh the data, you can select Reload from the context menu of the current account position view.

Selecting a particular stock will trigger the market history trend line and news module to be displayed. As soon as the current account position is loaded, the Stock Trader will automatically start proactively caching the market history.

Note

The main goal of the Account Position Summary is to demonstrate:
- Caching to isolated storage
- Exception handling with WCF Data Services
- Logging
- Tracing with asynchronous messages

Analyze Market Trends

When a user selects a particular stock in the Account Position module, the trend line view will show the history of that particular stock in a graph.

To improve the startup performance of the trend line view, the information is proactively cached to isolated storage. That means that the cache is populated on a background tread. Since the data is cached to isolated storage, it will also be available when the application starts.

Note

The main goal of the market history is to demonstrate:
- Proactive caching
- Caching to isolated storage
- Logging

Read Relevant News Articles

When a user selects a particular stock, a list of relevant news articles is shown for that stock. Selecting the article will cause its full text to be displayed.

Note

The main goal of the news module is to demonstrate:
- Caching to the in-memory cache
- Using Unity Interception to asynchronous services.
- Using Unity Interception to apply exception handling to asynchronous services.

Place Orders to Buy Or Sell Stock

From the list of stocks in the account position view, users can choose to place orders to buy or sell. An order can consist of multiple requests to buy or sell a particular stock.

Validation of input and business rules is an important part of the user experience. While the user is editing, he should get visual feedback of any errors, but this feedback should not interrupt him in his work. If there are still errors when the user tries to submit, he should get a message saying that there were additional validation errors.

The user should not be able to submit an order that has errors. Some validation rules should be implemented as warnings and the user should be able to continue submitting after a warning.

The business group also wanted the ability to add additional validation rules without having to recompile and redeploy the application.

Note

The goal of the orders module is to demonstrate:
- The defining of validation rules in code
- The defining of validation rules in configuration
- The use of validation rule sets
- Validation in a WCF Data Services application
- Complex type validation
- Building a ViewModel using a base class
- Logging
- Asynchronous tracing

Editing Current Account Holder Information

Users should be able to view and update their own account information, including their personal information, preferred risk tolerance, and their bank accounts.

Input and business rule validation is important here too. And while users can add multiple bank accounts, only a single bank account can be marked as primary.

Note

The goal for the account holder module is:
- Validation using Enterprise Library
- Sharing validation rules between client and server
- Validation in combination with WCF Data Services (Technique demonstrated also works with regular WCF services)
- Building view models

Guidance Module

The guidance module has been added to provide a description of the functionality for the stock trader from within the application. It helps explain the workings of the application.

Capture Diagnostic Information

One of the reasons the old Stock Trader was difficult to maintain was the lack of good diagnostic information. For Stock Trader V2, there were a couple of requirements for diagnostic information:

Developers should be able to view a developer trace log. This log should display all diagnostic information that is gathered by the application. Developers should be able to group this information by activity or category.

Power users should be able to see a log file with important log messages. This log file should be stored on the end user's hard drive so that it is not lost when the application restarts. Power users can reach the log view by adding #/IsolatedStorageLog to the URL, so that the URL looks like this: https://localhost:48902/Default.aspx#/IsolatedStorageLog.

• The IT support organization needs to be able to detect problems with the stock trader. When an unknown problem occurs on the Silverlight client, the application must report the problems to the server where they need to be added to the server's Windows Event Log. System Center Operations Manager will monitor the server’s event logs and report any problems to the end users.

Stock Trader V2 Architecture

In this topic, we’ll discuss the overall architecture of the Stock Trader V2. An LOB Silverlight application, like the StockTrader V2 reference implementation, typically consists of a Silverlight client and a web application where the Silverlight application is hosted.

The following diagram shows the general layering that’s applied to Stock Trader V2.

The user interface follows the Model View ViewModel pattern. The goal of this pattern is to separate the view from the view’s logic and data. The reason for the separation is that the view is typically a user control and difficult to test using automated unit tests. The logic is encapsulated in a special ViewModel class, which is then easily unit tested.

You can read more about the Model View ViewModel pattern in the MVVM documentation from Prism on MSDN, and in Karl Shifflet’s In the Box Training.

The Silverlight application accesses several web services, which are exposed by the web server. These web services are implemented using various technologies, such as WCF, WCF RIA Services and WCF Data Services. The logic to interact with these services has been encapsulated in special service agent classes. This isolates the View Model from web service-specific implementation details and also improves the testability of the View Model.

The business entities are shared between the client and the server. Each web service technology has its own method for achieving this. For example, WCF RIA Services uses a code generator to generate the business entities on the client.

On the server, the web services use an entity model to define the business entities and the object relational mapping to the database. The business entities also typically define certain validation rules.

Modular Development

The Silverlight part of the Stock Trader has been developed as a modular application. That means that it has been divided into several discrete modules. Each module addresses a functional area, such as news, account position, or orders.

Ed Says:

Dividing the Stock Trader V2 into several discrete modules turned out to be a really good idea. It allowed each module to be developed, tested, and deployed in isolation. It also helped us to implement a clear separation of concerns between the application's horizontal capabilities, such as logging or exception handling, and the vertical capabilities, such as processing an order or editing an account holder. </td>

The following diagram shows the modules for the Stock Trader V2 reference implementation:

The following assemblies will be packaged into the StockTraderRI.XAP:

• StockTraderRI. This is the main shell, which references all modules and knits them together into a single application. It also contains the views and styles that determine the general look and feel for the application. The shell knits together these functional modules:
  • StockTraderRI.Modules.News
  • StockTraderRI.Modules.Position
  • StockTraderRI.Modules.Orders
  • StockTraderRI.Modules.AccountHolderInfo

• StockTraderRI.Modules.Guidance. The guidance module is used to describe the functionality of the Stock Trader V2 reference implementation from within the reference implementation itself.
• StockTraderRI.Infrastructure. The infrastructure assembly contains generic functionality that is used by all modules.
• StockTraderRI.Infrastructure.ModelSupport. The ModelSupport assembly contains classes that help you with the most common tasks when using the Model-View-ViewModel pattern, such as implementing INotifyDataErrorInfo and INotifyPropertyChanged on your models.

The web application consists of the following parts:

• StockTraderRI.Web.
  The StockTraderRI.Web is a web application that hosts all the web services. It also hosts the Silverlight XAP file and the main page that is used to launch the XAP file. The WCF RIA Services for news and orders have been placed into separate projects:
  • StockTraderRI.Orders.Web
  • StockTraderRI.News.Web

Next Topic | Previous Topic | Home

Last built: July 8, 2011