DPS907 WSA500 Lab 5

Best practice web service implementation. Hosted on Azure.

Read/skim all of this document before you begin work.


DPS907 WSA500 Lab 5 – Due Mon Oct 19

Due date: Monday, October 19, 2015, at 8:00am ET

Grade value: 5% of your final course grade

If you wish to submit the lab before the due date and time, you can do that.

Yes, your project can earn part marks if a feature is missing. 



Create a simple web service, and use all of the accumulated best practices to date; deployed to Azure.


Introduction to the problem to be solved

We need a simple app, that enables a user to write a product review. Assume that this app is needed by a company that makes and sells products. The product review is a simple entity, and for this assignment, is not associated with another entity.

Your work will be hosted publicly on Microsoft Azure Services.


Specifications and work plan

The following specifications apply to all of your work:

  • Follows best practices
  • Implements the recommended system design guidance
  • Uses Entity Framework and Code First technology

For this assignment, here’s what we’re looking for:

  • Implementation of a small number of useful fetched resources
  • A user can create (author) a product review
  • And, a user can edit (change) the text of the review, and the score (value of the review)
  • After a review has been read by other users, they can indicate that the review was helpful
  • Deploy to Microsoft Azure Services

DPS907 students must attempt a refactoring task on the entity-specific repository; this will be explained later.


Getting started

Download and install the “Web API project v1” project template that you learned about in the October 15 class notes.

Create a new project, named “Lab5”, based upon the above project template.

Build/compile before continuing.


design-model-classDesign model class

This app needs only one entity class, probably named “ProductReview”. Here’s some info about the purpose of the properties in your professor’s example solution:

Timestamp – The date and time when the object is created. It is programmatically assigned. (The user or web service requester does not provide its value when a new object is created.)

ProductName – As it suggests, the product’s name. For example, “iPhone 6s”.

Location – The reviewer’s location. For example, “Toronto”, or “San Francisco”.

ReviewText – The text of the review. The review could be lengthy, so don’t limit its size to an unreasonably small value.

ReviewScore – Out of 10, the reviewer’s score for the product.

HelpfulCount – Stores the number of times that readers decided that the product review was helpful, based on feedback. It is programmatically assigned. (The user or web service requester does not provide its value when a new object is created. However, a command will enable a requestor to increment the value.)



At this point in the course, you probably follow a task checklist. If you don’t, create one. It will probably have some of these items on it:

  1. Update the data context to include the DbSet<TEntity> for the design model class(es)
  2. Author/create the resource model classes for each entity
  3. Write the AutoMapper create-map statements
  4. Create the entity-specific repository class(es), and add a property to the unit-of-work class
  5. Create the entity-specific controller

After learning this week’s topics, you will have a few more items to add to the checklist.


Entity-specific repository class

The class will have methods that do the following tasks:

Get all – Get all product reviews.

Get one by identifier – Get one product review, using its identifier.

Get recent – Get the most recent five (5) product reviews. It’s easy to do this if you use the Take() extension method.

Get highest rated – Get the highest-rated five (5) product reviews. Again, use Take().

Add new – Enables a new product review to be added to the persistent store.

Edit existing – Enables specific fields (review text, and review score) to be edited/modified.

Increment the “helpful” count – This is a command. It simply increments the existing value of the “helpful” property, and saves the result.


Controller work

The controller will implement the use cases that match the tasks you coded in the repository (above).

When a result returns an item or collection, it must use link relations.

Make sure that the public methods have XML Documentation Comments.


Other cleanup

The app’s “root” controller needs to be edited, to identify the app’s resource(s).

The localhost “server” port should be changed, to avoid configuration collisions with other apps that are based on the project template. Follow the procedure in the document below to do that. It’s near the bottom of that document.

Custom Visual Studio 2015 project templates


DPS907 (BSD) students will attempt this refactoring task

All students have learned that:

  • The repository methods return items or collections (to the controller) that are based on resource model classes
  • When appropriate, the controller will convert the item or collection to include link relations 

This design approach is valid, because we typically use the controller to do work that supports the intent of the use case. A controller method is nearest to the user/requestor, so it can make sense to transform a object or collection into a package with link relations here.

However, it can be argued that a pure web service will always deliver items or collections that include link relations. Therefore… maybe the repository methods should do this work. This would reduce the amount of code needed across many controllers.

Your task is to carefully study and plan to move the appropriate logic from the controller method(s) to the repository method(s).


Deploy your work to Microsoft Azure Services

Deploy your work to your “labs” web site on Azure, into the “lab5” virtual application. How?

Study this document, and watch its how-to videos.

If you are unable to deploy your work to Azure, then ask for help. Do not worry about “losing marks”, because Azure deployment is only one of several items on the checklist.

You must still submit your work (to My.Seneca/Blackboard) before the due date.


Testing your work

Use Fiddler.

Ensure that it has been configured to save the message bodies in requests and responses. (A default installation does not do this.) If you are using a College computer, this has already been configured. If you installed Fiddler on your own computer, follow the instructions on this document.

Test all scenarios (use cases), using your Azure-hosted web site.


Saving – ‘exporting’ – your tests

On the left side list of requests, you can delete items that you don’t want included in the export.

When you’re ready to save, choose File > Export Sessions > All Sessions…

The export format will be “HTTPArchive v1.2″. Click the Next button to choose a save location (your project’s root, in the same folder as the “packages” and “lab5” folder) and specify a filename. Name the file by using the project name (e.g. “lab5.har”).

(You can test whether the export was successful. How? First, close then re-open Fiddler. Choose File > Import Sessions. Select “HTTPArchive” as the import format. Navigate to the folder that holds “lab5.har”, and select it. Finally, browse through the request-response sessions.)


Reminder about academic honesty

You must comply with the College’s academic honesty policy. Although you may interact and collaborate with others, you must submit your own work.


Submitting your work

At this point in time, you are familiar with the submission process:

  1. Copy your project
  2. Remove its packages, bin, and obj folders
  3. Zip and upload to the designated location on My.Seneca/Blackboard, before the due date

If you need more details, look at the info in assignments 1 through 4.



















%d bloggers like this: