DPS907 programming assignment – specifications 4

DPS907 programming assignment specifications, document 4, for the November 29 due date.


Link to the assignment overview document.

Link to the specifications document 1.

Link to the specifications document 2.

Link to the specifications document 3.


Due date, November 29, 2013, at 1:30pm ET

The overview document asked you to complete the following by Friday, November 29, 2013, at 1:30pm ET:

Deployed on a Windows Azure web site


Expectations for this final deliverable

For this final deliverable, you must complete the following tasks:

  1. Add some useful resources to your web service
  2. Complete any unfinished work
  3. Review your code, and edit to make it clean, standard, and commented (in other words, make it a pleasure to read); look for code refactoring opportunities
  4. Test your work (using Fiddler)
  5. Deploy to a public web server

These tasks are documented in the sections below.


Add some useful resources to your web service

In the previous deliverables, you have focused your efforts on building the foundations for your web service.

For this final deliverable, think about use cases. What data will users want? What tasks will they want to do?

Create a list of questions-and-answers (about five to ten), and then add some resources to your web service. (Remember the definition of “resource” that you learned in our first class/session together, on September 3.)

For example, would it be useful to deliver a collection of Course objects that are in the BSD Program? Yes, it would. There are probably two ways to think about this – from the perspective of a Program object, or from the perspective of the Course objects. Therefore, it could be done with either (or both) of these resource URIs:



Another example: Would it be useful to deliver a Course object, with a nested collection of GradedWork objects? Yes it would.

Another example: Would users want a list/collection of all “Lab” graded works? “Test” dates?

See how easy it is to come up with use cases? Add code to your web service (controller methods, view model classes, repository classes, etc.) to support these new resources. As noted above, you should add a reasonable number (five to ten).


Complete any unfinished work

If you did not complete the work required for deliverables 1, 2, or 3, now is the time to do that.

Follow best practices.


Review and edit your code

Review your code, and edit to make it clean, standard, and commented.

Add code comments (where appropriate) to ensure that you (in the future) and your professor (in the present) understand your thoughts and coding style. You do not have to comment obvious and simple code, but you should add comments to code that’s not obvious.

Make your code a pleasure to read.

Remove old code that you have commented out.

Format your source code to fix spacing, indentation, and related issues:
Edit > Advanced > Format Document
or by keystroke, Ctrl+E, Ctrl+D (or Ctrl+K, Ctrl+D depending on your settings)

Optional: If you want to suppress the compiler warning messages that begin with “Missing XML comment…”, you can change a project setting. Open your project’s properties page. On the “Build” tab, there’s a text field titled “Suppress warnings:”. In the text field, enter the number 1591 (that’s the error message number).

Look for opportunities to refactor your code to make it better. For example, each controller class has repeated code blocks to generate the HttpResponseMessage for the get-one, add-new, and update-existing methods. Can you replace the repeated code with calls to a new private method in the controller class?


Test your work

Use Fiddler to test your work. Save the results in a Fiddler session archive.

Normally, Fiddler’s “File > Export Sessions” settings include the body of the request or reply only if the number of characters in the body is very small. You must change a setting in Fiddler to increase the value. This post teaches you how to change the setting.

For each important entity, use Fiddler to send requests that cover your app’s functionality. For example:

  • get one
  • get all
  • other ‘get’ requests that show the results of your new use cases (above)
  • add new
  • update existing
  • delete existing (where appropriate)
  • any ‘commands’ (that follow the CQRS approach you learned on October 11 and in Lab 3)

Send these requests as different users (with different access tokens), to show the correct functionality.

Include the session archive alongside your project’s “solution” file (which is also at the same level in the file system as your project and “packages” folders, and the ‘publish settings’ file).


Deploy to a public web server

You should have already done this for deliverable 3.

Update (deploy) your web service to a Windows Azure web site.

When you zip-and-submit your project via My.Seneca/Blackboard, include the URI to your publicly-available Windows Azure web site.













  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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: