继续开发之前的Web, 围绕基于数据库驱动的ASP.NET核心开发MVC Web应用程序。
Introduction
The goal of this assignment is to build on the skills you have been developing around database-driven ASP.NET Core MVC web apps. This app is somewhat more complex than what you built in assignment #2 in that it has a richer data model, including a many-to-many relationship. As with assignment #2, you have some freedom to develop the app as you think is best given that we have been exploring some different ways of building ASP.NET Core MVC web apps. Some highlights of this assignment are:
- View models and attribute routing, while not required, are likely going to be helpful.
- You must implement your core business logic in a service.
- You must have an xUnit project that runs unit tests against your business logic.
- More practice applying LINQ and EF Core to a rich data model and then maximize the “hypermedia design” of your app to reflect the relationships between the entities in that data model - i.e. the app supports linking between the various entities.
- Practice implementing data validation constraints
- Apply the “soft delete pattern” and use it to support an undo of a delete action.
- Apply a “paging” solution to the vendors by clustering them into alphabetical groups.
- Apply some of ASP.NET Core’s mechanisms for reuse in Razor views.
First, a word of caution
I remind you to make sure you do your own work on this assignment and resist any urge to copy code from any other source - e.g. your classmates, the web, etc. Not only is this the only way to learn how to program but also everyone’s solution will be run through MOSS to check for academic integrity violations. There is zero-tolerance for such violations and any encountered with be dealt with in accordance with Conestoga’s policy. I also remind you that if you are not typing syntactically correct code in yourself you are not learning to program! Finally, I’ll note that these assignments are very representative of what will be expected of you on exams so it is very much in your interest to ensure that you are capable of doing them on your own.
Hints
The general idea is that there will be some time to work on these assignments in class and, if necessary, I can offer hints if I see that you are struggling with certain parts. Also, you should try to pace out your work on this assignment over the coming weeks.
How will it be graded?
I’ll say from the outset that there is absolutely no reason to not get 100% - the emphasis here is simple: get your hands dirty coding to solve basic problems and, if needed, I will do what I can to help steer you towards a working and complete solution.
Accompanying each assignment will be an Excel marking sheet that details how your grade will be calculated so you obviously want to make sure that you are doing everything as it’s laid out there.
What/how to submit?
Zip up your entire solution into one zip file and submit that file to the eConestoga dropbox for the assignment.You can submit multiple solutions but only the latest (i.e. most recent) one will be looked at and evaluated.
What will you build?
The app you will build for this assignment is to develop an app that supports the following basic features:
- Displays the vendors in alphabetical groups, e.g. “A - E” represents all the vendors whose name starts with a letter in the range A to E
- Add/edit a vendor with some validation requirements
- Soft delete a vendor
- Undo the action of deleting a vendor via an undo link that appears in the latest action message for a delete action
- View more details about a vendor including its invoices and be able to return to the previously viewed alphabetical group of vendors
- For each invoice of a vendor, be able to see both the total and the line items of the invoice
- And finally, be able to add a new line item to an invoice
To achieve this, there are 4 main pages that you need to develop:
- The Vendors page
- The Add Vendor page
- The Edit Vendor page
- The Vendor’s Invoices page
Before we get to all the detailed requirements for each page, let’s summarize both the starting code and some implementation requirements..
The Starting Code
There isn’t a starting solution but rather some C# class files in a zip file that each represent a starting point on the primary entities this app needs to work with and you will need to integrate them into your project where you see fit. The goal for the entities is to ultimately reflect the following domain model:
To complete this domain (or entity) model you will need to complete the entity classes by adding the following navigation properties:
- A property to navigate from a Vendor to all its invoices
- A property to navigate from an Invoice to its Vendor
- A property to navigate from an Invoice to all its Line Items
- A property to navigate from a Line Item to its Invoice
- A property to navigate from an Invoice to its Payment Terms
- A property to navigate from a Payment Terms to all Invoices that have those payment terms
Also, in addition to the entity classes, also included in the zip file is a text file with some code snippets that can be used to help seed your database with some entities.
The Code/Implementation Requirements
The idea is to use this assignment to practice structuring your Web App project in accordance with best practices. As such, your solution has the following code/implementation requirements:
- Your business logic consolidated in a scoped service that the controllers use to access and manipulate the application’s entities, i.e. Vendors, Invoices, etc.
- At least one separate class library that is used by your Web App
- An xUnit project that has at least 3 unit tests that can be run successfully against your class library project
- Avoid repetitive form elements in your Add and Edit Vendor pages by making use of a partial view that consolidates the common elements
Now, to flesh out the details of what you need to build, let’s consider each of the pages in turn
The Vendors page
This page should show:
- A link to take the user to the form to add a new vendor
- A group of links to display vendors from other alphabetical groups
- The link for the current group should be highlighted appropriately
- A table of the vendors with the columns:
- Name
- Address
- Actions. This means three links:
- An “Invoices” link to take the user to page showing all the invoices for that vendor
- An “Edit” link to take the user to the Add/Edit view to edit/update the current vendor
- A “Delete” link that deletes the current vendor. This result in two things:
- The vendor in question being marked for “soft delete” in the database
- A return to the previously viewed alphabetic group of vendors with a link to optionally undo that delete action
- An undo link contained within a dismissable last action message, after a delete action, and clicking it should undo the previous delete action. A few considerations about this:
- This should lead to the vendor appearing in the table again
- The undo action should not remain available indefinitely. You could either:
- Have it go away upon the next page refresh
- Or fade away after some period of time - just how Gmail gets rid if its undo action links after 6 seconds
- This could be done easily by using jQuery’s “fadeOut”, or some other similar animation.
- Hint: to do this the simplest approach is to add a boolean IsDeleted property (that defaults to false) to the vendor and:
- You only show vendors that are not deleted
- Soft deleting means set it true so that undoing that action is simply a matter of setting it back to false
The Add/Edit Vendor pages
These pages should:
- Show:
- A header describing what action is being completed - Add or Edit
- Labels and input elements for each field to be entered for a vendor
- Include a button that enables the successful completion of the Add (or Edit) action
- If successful the user should be returned to the previous alphabetical group they were viewing
- Otherwise the validation errors should be highlighted - please the section below for all the validation requirements for a vendor
- And a button that cancels the action and returns to the previous alphabetic group they were viewing
The Edit vendor page would of course be similar except that it preloads with the current vendor’s properties. Also, remember that this time you must make use of partial views to avoid repetitive form elements across both of these Add and Edit pages.
The Vendor’s Invoices page
This page should:
- Show:
- A heading the references that the user is viewing the invoices for a given company
- The company’s address
- Their payment terms
- Have a link that returns to the previously view alphabetical group of vendors
- That vendor’s invoices in a table on the left showing:
- The invoice number (i.e. the integer Primary Key for simplicity) which should be present as a hyperlink to show that invoice’s line items on the right
- Due date which should be implemented as a get-only property based on its invoice date plus the number of due days based on its payment terms
- The amount paid
- By default this page should first load showing the details - i.e. line items and total for the first invoice and thereafter it should show the same invoice details for whatever invoice is clicked
- Ideally the row for the currently selected invoice should be highlighted in some fashion
- For the current invoice, the user should also be able to add a new line item (form on the right) by entering the description and amount, which should show the new line item in the table and the total adjusted appropriately but otherwise stay on the same view.
- And similarly, the user should also be able to use the form on the left to add a new invoice for that vendor.
Validation requirements for adding/editing a Vendor
When adding/editing a vendor you need to implement the following validation requirements:
- Name, Address 1, City, Province/State, Zip/Postal code, and phone are all required
- Province/State must be a 2 letter state code - but case doesn’t matter
- Phone number must be:
- In a valid (US or Canadian) phone number format
- And the number must be unique within the database
- Zip/Postal code must be in a valid US zip or Canadian postal code format
- The contact email must be in a valid email address format
- In addition to these value-based validation requirements you need to support the following UI related validation requirements:
- If there are validation errors, then:
- There must be a generic message above the form indicating that there are errors in the form
- The fields in error highlight must highlighted in 3 respects:
- It must have a red border
- A different background colour - i.e. different from the valid or empty fields
- And a field-specific error message, in red, after (i.e. to the right of) the field in error
- If the phone number the user has entered for the vendor is not unique, then they should be informed of that conflict immediately - i.e. they should not have to wait to submit the add/edit button.
- If there are validation errors, then: