Chapter 4: The Media Library Example

In this chapter, we introduce the media library example application, which is the example that we will use throughout the rest of the book to illustrate how to do Test-Driven Development (TDD) when developing a real world application. The example application approximates an actual application, but it does not have the complete functionality of a finished application.

With this example, we want to depart from a common practice of omitting some of the difficult aspects of real application development ”such as error handling, robustness, performance, interoperability, evolving design around the legacy system requirements, and so on. However, to make such an example possible within the constraints of a book, we had to make compromises. We chose to reduce the features of the application but present a complete architectural crosscut. Much more functionality would be required before the software would really be released. Because our intent is that this application can evolve into the actual application, the design and implementation of what we present is intended to be production-ready. The code you see should handle errors correctly and be a suitable design with which you can build to complete the application.

The Skinny

Our fictitious company has a large existing database of musical recordings. The content of the database is sold to other companies to build user -friendly applications. To keep the data as current as possible, we sell updates to the data on a quarterly basis. Because new recordings are released weekly, the quarterly updates are out-of-date almost immediately and insufficient according to our customers. The far-too-infrequent updates cause customers to insert new recordings in their own copies of the data. These updates are done manually, and the data entered are not always clean. (They include mistyped recording titles and incomplete track information, to name a few problems.) When our quarterly updates arrive , the database administrator has to merge the changes from our update into their database. Such merging is usually painful because of the dirty data and it often requires manual intervention by the database administrator.

Also, the customers forward the changes they have made to the content to us for inclusion in the next quarterly update. Our company is responsible for verifying the quality of this data and including the validated update into the next quarterly update that is distributed to all our customers. Some of our customers submit their changes late, and because of the required verification and merging, some updates might miss the deadlines to the quarterly update schedules (making our customers unhappy ).

To improve the timeliness of the data, we decided to provide direct access to the clean data in our database while we preserve our control over the integrity of the data. To do this, we decided to build a service-based architecture around our data to provide the customers with a constantly updated repository of musical recordings. Our goal is to eliminate the need for the customers to maintain their own copies of the database. Another goal is to allow our customers to do updates to the data in the master database as they do now in their local copies, but to reduce the overhead on our side associated with the merging of such updates with updates of other customers.

One thing to keep in mind is that our customers deploy their solutions on a number of different platforms, so it is imperative that whatever we provide must be interoperable with our system. To that end, we intend to use Web services as the means of interoperability for access to the data. We will also provide a browser-based client to allow customers to insert new recordings and edit existing ones.

Existing Database

By far, the largest constraint is the existing database. Our company has been selling this database, which is hosted in Microsoft SQL Server 2000, for the past few years . It contains hundreds of thousands of recordings with millions of tracks. For this project, the database administrators of our database do not see why they should change the schema. We currently do not have any requirements that would cause us to change the schema, but the database administrators do not want us to change it. Therefore, we will view the schema as a constraint that we have to live with for the project. If it becomes a critical issue, we might raise it again later, but with some data to back up our needs. The existing data model is shown in Figure 4-1.

Figure 4-1: Recordings data model

The following sections briefly explain this data model.

Entities

The two primary entities in our data model are Recording and Track. A Recording is something that is publicly released by a music company on some type of media (compact disc, audiocassette, vinyl, and so on); this company is referred to in the model as a Label. A Track is a complete song. Each Recording also has a title and the date on which it was released. Each Track has a title and duration.

We also have a few secondary entities in our model that we use mostly to normalize the relational data:

Genre This entity represents different musical styles; for example, rock, classical, pop, hip hop, and so on.

Artist This entity is the name of the person or group that is the performer.

Label This entity is the company that released the recording.

Review This entity, which describes a critique of the recording, is written by a Reviewer. (Each reviewer has a name.)

Entity Relationships

Each Recording has many Tracks, one Label, one Artist, and many Reviews. Each Track has an Artist and a Genre. Each Review has one Reviewer. We have a special category of Various Artists to use as the artist for Recordings and Tracks performed by more than one artist. In the current model, we do not support individual track Reviews.

In Figure 4-1, the rightmost column in each table has special constraints associated with the corresponding attribute (listed in the leftmost column). For example, in the Track table, you see the PK (short for primary key) constraint associated with the trackId attribute, which means that the trackId attribute serves as the primary key in our database Track table. Similarly, the FKx (which stands for foreign key) constraint is used to describe a relationship between two entities. For example, the Track table has a foreign key constraint ” FK1 ” associated with the genreId attribute to indicate that this attribute is used to capture an association between a Track and its Genre.