DPS907 WSA500 Lab 1

Your first small assignment, known as Lab 1. Gets you started with web services, and results in a ‘template’ that you can use in the next few weeks.

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

.

DPS907 WSA500 Lab 1 – Due Tue Sep 16

Due date: Tuesday, September 16, 2014, at 8:00am ET

Grade value: 3% of your final course grade

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

.

Objective(s)

Assemble a project template that you can re-use during the first few weeks of the course.

Get started with web service coding and testing.

(Please note that the Microsoft Azure part of this lab was removed and is not required.)

.

Introduction to the problem to be solved

The “file > new > project” result does not include all the components we need for a typical web service project. You will solve that problem by creating a project that you can use as a ‘template’ during the first few weeks of the course.

The simple web service will persist data (one entity), and support a limited number of HTTP methods.

.

Specifications and work plan

Here’s a brief list of specifications that you must implement:

  • Follows best practices
  • Implements the recommended system design guidance
  • Entity Framework; also supports migrations
  • Supports HTTP GET and POST
  • Includes a log file that shows complete coverage of tests

.

Getting started

The name of your project will be “Lab1”.

Create a project, using the “Web API” template. No authentication. No hosting (yet).

As you perform each step, test your work, to ensure that you’re making error-free progress:

  • Build/compile
  • Where appropriate, use Fiddler

.

Adding components

Persistent store

Use the NuGet Package Manager to add the Entity Framework to your project.

Add a connection string to the project’s Web.config file. It follows the “configSections” element, and looks like this:

<connectionStrings>
<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\project-specific-name.mdf;Initial Catalog=project-specific-name;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>

Design model classes

In the Models folder, create a source code file named DesignModelClasses.cs. In that source code file, create an entity class to describe a smartphone. Write five or more properties (your choice, but use common sense). Use different data types. For example:

  • Id (identifier)
  • Manufacturer name
  • Smartphone model name
  • Release date (date; see below)
  • Screen size (double)
  • Sell price (integer)

Facade services

In the Models folder, create a source code file named DataContext.cs. In that source code file, create a class for the data context. It will (obviously) include a DbSet<TEntity> property for the ‘smartphone’ entity class.

In this same source code file, create a class for the data store initializer. Write code (for the Seed() method) that will create two or more objects when the app loads for the first time.

You will have to edit the HttpApplication class (in Global.asax.cs) to call the store initializer.

Resource model classes

You know about “view models”. In web service documentation, these classes are often called “resource models”. They’re the same.

In the Controllers folder, create a source code file named Smartphone_vm.cs (or something similar to match the entity name you created earlier). It will hold resource model classes for these use cases:

  • List
  • Add
  • Base

Obviously, we need program code to map between design model and resource model classes. We will continue to use AutoMapper. Therefore, using the NuGet Package Manager, add AutoMapper to the project.

You have learned that the ideal place to locate AutoMapper ‘create map’ statements is in the HttpApplication class. Therefore, add the right number of statements. You need a map from design model to resource model, and another to enable the ‘add’ use case (resource model to design model).

‘Manager’ class for data service operations 

In the Controllers folder, create a source code file named Manager.cs. Its purpose is to contain the methods that perform data service operations. Controllers will call into this ‘manager’ class.

Like all manager classes, it needs a field for the facade reference (the data context). Then, it will need (for this lab) methods for:

  • Fetch all objects in a collection (should they be ordered?)
  • Fetch a specific object based on its unique identifier (what happens if not found?)
  • Add a new object to the collection

Controller class

Finally, in the Controllers folder, create a source code file named SmartphoneController.cs (or something similar to match the entity name you created earlier). On the scaffolding selector dialog, choose the ‘Web API 2 controller with read/write actions”.

Like all controller classes, it needs a field for the ‘manager’ reference. Then, three of its methods need to be implemented:

  • Get all
  • Get one
  • Add new

Entity Framework Code First Migrations

The final task – after you have tested your work – is to configure ‘migrations’. This feature enables us to keep data after making changes to design model classes.

This note has full coverage of the topic (see the section titled “Design model updates, and Code First Migrations”). However, here’s the minimum that you have to do for this exercise:

In Visual Studio, open the TOOLS menu. Choose ‘Library Package Manager’, then ‘Package Manager Console’. That will open a command-line window/panel.

Type the following command. It’s a once-per-project command. After you do this, you will not have to do it again for the current project:

enable-migrations

This command configures the base or start state of your the app domain data model, and its persistent store implementation.

Now, disable the loading of the store initializer object, because we will manage the ‘seed’ process in a different way.

.

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).

When testing the ‘add new’ scenario, remember:

  • The HTTP method is POST
  • The target is the collection URI
  • The message body needs a JSON object that matches the ‘SmartphoneAdd’ resource model

The date (i.e. DateTime type) property needs some explanation. The JSON serializer uses the ISO 8601 standard for dates and times. For example the due date and time of this lab is expressed as a string, “2014-09-16T08:00:00”. In other words the date is in year-month-day format. Then there’s a letter “T”. Finally, the time is in hour-minute-second format.

Assuming that you used a store initializer to create some initial data, study the results of a ‘get all’ or ‘get one’ request. Notice the date-time format. Use that format when you enter the string for the date in your ‘add new’ requests.

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 “lab1” folder) and specify a filename. Name the file by using the project name (e.g. “lab1.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 “lab1.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

Here’s how to submit your work, before the due date and time:

1. Locate the folder that holds your “Lab1″ project files.

2. Make a copy of the folder. This is the data that you will be uploading.

3. Remove the “packages” folder from the copied folder; also, remove the “bin” and “obj” folders.

4. Compress/zip the folder. The zip file SHOULD be about 1MB or less in size. If it isn’t, you haven’t followed the instructions properly.

5. Login to My.Seneca. Open the Web Services Architecture course area. Click the “Assignments” link on the left-side navigator. Follow the link for this lab. Submit/upload your zip file. The page will accept three submissions, so if you upload, then decide to fix something and upload again, you can do so.

.

.

.

.

.

.

.

.

.

.

.

.

.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: