Net Portfolio Shade

S H A D E O L A G E S H I N

.NET PORTOLIO

Shade Olageshin .NET Portfolio Page 1

Library – Windows Front-End Application (Phase 1)

Objective

A database has been created to support the principal functions of a lending library‟s day-

to-day operations: adding new members (adult and juvenile) and checking books in and out. An assembly has been created that contains classes and interfaces that provide access to the database for these functions. What is needed is a Windows Forms-based

front-end application that will provide a librarian with a visual interface through which he or she may perform the desired functions. Creating that application will be your task.

Provisions • An interface that specifies the methods supported by the Data Access tier used for

all database access and a class that implements the interface are provided.

Classes that represent various “business entities” (e.g., an AdultMember class) are also provided. Detailed information appears in Appendix B.

• A reference implementation that illustrates one possible solution for this project is provided. The reference implementation is not intended as a model to be emulated in your solution; rather, it serves only to illustrate how you might

implement your solution, rather than how you must implement your solution. If you wish to use the reference implementation as a basis for how your

implementation will appear and function, you are free to do so, but you are not obligated to replicate the appearance of the reference implementation.

Validation

• First name, Last name must be non-empty strings consisting of alphabetic

characters only, with a leading uppercase character and all others in lowercase, at most fifteen characters in length.

• Middle initial is optional, but if entered it must be one uppercase alphabetic character.

• Street address and city must be non-empty strings, no more than fifteen

characters in length each. • State must be two uppercase alphabetic characters.

• Zip must be a non-empty string in the format: ##### or #####-####, where # is a digit (0-9).

• Phone is optional, but if entered it must be in the format: (###)###-####.

• For a juvenile member, birth date must be a valid date (MM/DD/YYYY format), and the birth date must fall within the eighteen-year period ending on the

current date. • ISBN, Copy number, and Member ID must be positive integer values (>0).

ISBN must be a 32-bit integer value. Copy number and Member ID must be

16-bit integer values.

Overview of Library Operations Before a database to support library operations was implemented, an interview was conducted with the librarians who would be performing these operations using the new

application. The following sections describe the considerations that influenced the design and implementation of the database.


Uniquely Identifying Books

Some books may have the same title; therefore, titles cannot be used as the sole means

of identification. Librarians call books items. Items are identified by the International Standard Book Number (ISBN). Books with the same title can have different ISBN

numbers if they are in different languages and have different bindings (hard cover or soft cover). Multiple copies of a given item may be held in the library‟s collection. Copies of a given item are numbered with copy numbers from 1 through n, where n is the number of

copies of that item. A physical item is thus uniquely identified by the pairing of its ISBN and its copy number.

Enrolling Members

To become a library member, an individual must provide his or her mailing address and, optionally, his or her phone number. A librarian then issues the individual a numbered,

machine-readable card. This card is good for one year from the date of issue.

Juveniles are considered to be individuals under the age of eighteen. A juvenile can be a

member of the library, but must have an adult member sign for them when they join. The juvenile‟s address and phone number information is that of the sponsoring adult member, and the juvenile‟s card is valid only until the sponsoring adult member's card expires. The

only information that the library keeps on a juvenile member is his or her name, sponsoring adult member card number, and his or her date of birth.

Checking Out Books

Books are checked out for 14 days. Members are allowed to have at most four books

checked out at a time. Members bring books to the front desk after they locate the ones that they want to check out. A librarian then enters the card number from the member's card. A screen displays information about the member's account, such as name, address,

phone number, and the card's expiration date. Ideally, cards that have expired will be highlighted. The screen also displays information about a member's outstanding loans,

including title, checkout date, and due date.

If a member's account is in order (i.e., the card is not expired and fewer than four books are on loan to the member currently), a librarian checks out the books. Librarians check

out books by entering the ISBN and copy number of the item, both of which appear in a label on the book‟s spine. The ISBN, copy number, title, and author information then

appear on the computer screen so that the librarian may verify that the database entry corresponds to the item being checked out. The librarian then can elect to check the book out or to cancel the check-out operation.

Occasionally, books are accidentally re-shelved before librarians check them in. If a librarian tries to check out a book that the database lists as already checked out, the

librarian should be alerted and be given the opportunity to check the book in before proceeding with the check-out operation.

Checking In Books

When a book is returned to the library, a librarian checks it in by entering the ISBN and

copy number that appears on the book‟s spine. The ISBN, copy number, title, and author information then appear on the computer screen, as well as the card number and name of the member to whom the book is checked out, and the book's due date. The librarian can

then elect to check the book in or to cancel the check-in operation.


Data Validation

To enroll an adult member, the required fields are:

• First name

• Last name

• Street

• City

• State

• Zipcode

Middle initial and phone number are optional fields.

To enroll a juvenile member, the required fields are:

• First name

• Last name

• Adult member ID

• Birthday

Middle initial is an optional field.

First name and last name fields must be validated to ensure that the values contained in these fields are alphabetic only and that the first character of each of these fields is

uppercase.

The Zipcode field must be validated to ensure that only a five-digit (XXXXX) or a nine-

digit (XXXXX-XXXX) value is entered.

If a value is entered into the middle initial field, that field must be validated to ensure that the value entered is a single alphabetic character.

If a value is entered into the phone number field, that field must be validated to ensure that the value conforms to the format (XXX)XXX-XXXX, where X is a digit from 0 through

9. Note there is no space after the right parenthesis; the field in the database for the phone number is thirteen characters long, so including a space at this point would cause the phone number to be truncated.

The adult member ID field must be validated to ensure that it contains only a numeric value in the range 1 through 32767 inclusive.

The birthday field must be validated to ensure that it contains a value in the format MM/DD/YYYY and that the value parses to a date that is no more than eighteen years prior to the current date.

When a member ID is entered to perform a member lookup, that field must be validated according to the same rule specified for the adult member ID field above.

For the ISBN and copy number fields used in the check-in and check-out operations, these fields must be validated to ensure that only numeric values are entered. For the copy number field, the value must be in the range 1 through 32767 inclusive.


MDF Container – Matthews’ Library Interface

Diagram 1 – MDF Parent (Library Main Window)

Diagram 1.1 - add juvenile Diagram 1.2 – add adult

Matthew’s Library - Menu Items

File

Close – Closes the Application

Edit Members

o On clicking on a menu item a new window opens up to perform the

specified function

Add Adult

Add Juvenile


o These menu items are disabled until a member id has been entered into

the view member form or a new member has been added.

Check In

Check Out

View Members

o On clicking on this menu item a new window opens up

Get Member Information

public Member GetMember(short memberId)

{ member = lda.GetMember(memberId);

}

using (SqlConnection conn = new SqlConnection(connectstring))

{ using (stproccmd = new

SqlCommand("dbo.get_Adult")) {

stproccmd.CommandType = CommandType.StoredProcedure; stproccmd.Connection = conn;

SqlParameter input = new SqlParameter(); input.DbType = DbType.Int16;

input.Direction = ParameterDirection.Input; stproccmd.Parameters.AddWithValue("@member_no", memberNumber); conn.Open();

adult = new AdultMember();


Validation

Member ID must be 16-bit integer values.

Get Member (unpopulated)

Get Member (Juvenile Type)


Data Validation

To enroll an adult member, the required fields are:

• First name

• Last name

• Street

• City

• State

• Zipcode



Required Functionality – Stored Procedures (Phase II)

CREATE PROC [dbo].[add_Adult]

--Member properties

@insertMemberID smallint OUTPUT,

@lastname varchar(15),

@firstname varchar(15),

@middleinitial char(1)=NULL,

@photograph image = NULL,

--adult properties

@street varchar(15),

@city varchar(15),

@state char(2),

@zip varchar(10),

@phone_no varchar(15)=NULL

, @expr_date datetime OUTPUT

AS

BEGIN

IF @lastname IS NULL OR

@firstname IS NULL

BEGIN

RAISERROR('You must provide name information',10,1);

RETURN -10

END

BEGIN TRANSACTION

INSERT Member (lastname,firstname,middleinitial,photograph)

VALUES (@lastname, @firstname,@middleinitial,@photograph)

IF @@ERROR <> 0

BEGIN

RAISERROR ('Error during insert of member', 15,1);

ROLLBACK TRAN

Data Validation

To enroll a juvenile member, the required fields are:

• First name

• Last name

• Adult member ID

• Birthday


Data Validation

ISBN, Copy number, and Member ID must be positive integer values (>0). ISBN

must be a 32-bit integer value. Copy number and Member ID must be 16-bit integer values.

Error provider for

Data Validation

The birthday field must be validated to ensure that it contains a value in the

format MM/DD/YYYY and that the value parses to a

date that is no more than eighteen years prior to the current date.


Error provider for Data Validation

For the ISBN and copy number fields

used in the check-in and check-out

operations, these fields must be validated to

ensure that only numeric values

are entered. For the copy number field, the value

must be in the range 1 through

32767 inclusive.

Multiple windows capabilities


Member ID 962 page with check in form - prior to ISBN 8, copy 3 being checked

in

Member id 962 after book check in


Required Functionality – Cancel Checkout(Card Expired)

If a member's account is in order (i.e., the card is not expired and fewer than four books

are on loan to the member currently), a librarian checks out the books. Librarians check out books by entering the ISBN and copy number of the item, both of which appear in a

label on the book‟s spine. The ISBN, copy number, title, and author information then appear on the computer screen so that the librarian may verify that the database entry

corresponds to the item being checked out. The librarian then can elect to check the book out or to cancel the check-out operation.


Library – Windows Business & Data Access tiers (Phase 2)

Requirements

• Design the Business and Data Access tiers

• Develop code that is easily maintainable.

• Provide adequate error handling.

• Use database-programming techniques that provide maximum programming flexibility and control while minimizing resource utilization.

• Work with your instructor who will act as the project DBA for any required SQL

help. Library Database Design

Based on the information that librarians presented, the project database designer decided to implement the entities from the scenario presented in Phase 1 of the Library

Project in three groups of tables: tables that contain member information; tables that contain item (book) information; and tables that contain loan information.

Member Information

The member table is the master table, while adult and juvenile are subtables. All three

tables use the member_no column as a primary key. The member_no column in the member table is also an autoincrementing column; i.e., it is an identity column. Since a

member is identified uniquely by his or her member number, the member_no column is a good choice for a primary key.

These entities could have been modeled alternatively in a couple of different ways: as a single table; or as member and juvenile tables. If a single table had been used for all members, many addresses would have been duplicated because juveniles in this model

have the same address as their parents. Since birth dates must be stored only for juveniles, splitting the membership information into several tables eliminates the null

column values that would have resulted for the birth dates of adults. Dividing the tables in this fashion also models the scenario in a way that reflects the membership of the library: member-toadult is a one-to-one relationship, while adult-to-juvenile is a one-to-many

relationship.

Loan Information

The reservation, loan, and loanhist tables contain the library's loan information. The

reservation table tracks current reservations for each book; the loan table tracks information on books that are currently on loan: and the loanhist table stores information on books that have been loaned and returned. It is possible to combine the loan and

loanhist tables to reduce redundancy, but this may create other problems.

The loanhist table is essentially a history of all loans and could become unwieldy. Over

time, librarians may want to back up information from this table, so it makes sense to keep all of this information in its own table. In addition, this business model requires

that several queries be made against the loanhist table. These queries would be easier to implement and faster to run if the history information were kept separate from the loan information.

The loan and loanhist tables also represent different functions of the application. When a member checks out a book, an entry is made to the loan table. When a member returns a

book, an entry is made to the loanhist table, and the corresponding entry is deleted from


the loan table. By maintaining separate tables for each function and denormalizing the tables, users can access the information more quickly. However, because the tables are

denormalized they require more maintenance. For example, when item.title_no is updated, the title_no column must be updated in the loan, loanhist, and copy tables as

well. Because updates to the title_no column may be infrequent, denormalization may speed queries.

Required Functionality

In Phase 1 of this ongoing project, you were provided with an assembly that

encapsulated all the data access logic for your application. The assembly in Phase 1 employed ADO.NET to provide access to the library database. It did not, however, use any stored procedures, which could have made database operations more efficient. In

Phase 2, you are to design and implement your own business and data access tiers. Use stored procedures which must be commented thoroughly and your code should not

contain any SQL statements.

You were also provided an assembly that contained business entity classes needed for

the project (e.g., Item, ItemsDataSet, Member, etc.). You must not use either of the assemblies that were provided to you in your Phase 2 project. You must implement the business entity classes yourself.

In Phase 1 of this ongoing project, verification that an item presented for checkout is loanable was not a requirement. In this phase, you must perform that verification and

prevent an item that is not loanable from being checked out.

Focus your efforts on the following:

• Add Adult: Rows are added to both the member table and the adult table

• Add Juvenile: Verification that the sponsoring adult member‟s record exists (and is unexpired) must be performed. The juvenile‟s age should be verified that is an acceptable

age of a juvenile. Rows are added to both the member table and the juvenile table.

• Checkout item: Verification that item exists and is not already on loan must be performed. Verification that item is loanable must be performed. Row is added to loan

table. Update copy table‟s on_loan field to „Y‟.

• Checkin item: Verify that the item exists and is on loan. Delete row from loan table. Add row to loanhist table. Update copy table‟s on_loan field to „N‟.


Required Functionality –add Juvenile

Add Juvenile: Verification that the sponsoring adult member‟s record exists (and is unexpired) must be performed. The juvenile‟s age should be verified that is an acceptable

age of a juvenile. Rows are added to both the member table and the juvenile table.


Get Juvenile after adding to database

Juvenile table with newly added member

Required Functionality - Checkout


Checkout item: Verification that item exists and is not already on loan must be performed.

Verification that item is loanable must be performed. Row is added to loan table. Update copy

table‟s on_loan field to „Y‟.

Member # 1235 , with no items on loan, Checking out book ISBN #7, Copy #1,

already on loan to another member

Confirm check out, check in from loan to other member information returned by

Library Exception

catch (LibraryException le) {

String message="ISBN #" + isbn + " Copy # " + copyNumber + " already on loan to if (memberID == le.OtherMemberID)

{ checkOutToolStripStatusLabel.BackColor = Color.Blue;


Member #1235 page after Checkout

Loan history table


Web Application (Phase 3) Requirements: Create a web application that supports all the functionality required for

Phase I and II of the Library project. Additional requirements:

When displaying an adult's information, the application should detect if the card

is expired and give the librarian a chance to renew the card. Librarian must be

able to choose whether or not to renew the card. The renewal date is today plus one year.

Members cannot check out books if the card is expired.

When dealing with juveniles, the application should detect if the juvenile is 18

years old or older and convert the member to an adult (row deleted in the juvenile table, row added to the adult table). This operation is not at the

discretion of the librarian; i.e. the upgrade must take place automatically and the librarian must be notified that the upgrade has taken place.

Overdue books, shown in any display, must be highlighted.

The librarian must be able to enter a new book into the database. If the ISBN already exists in the database, all that is needed is to add a record for a new

copy number. If the ISBN does not yet exist in the database, you must add all necessary records for the new ISBN and a new copy number 1 for that ISBN.

Use of hyperlinks to navigate between pages.

Project locations and requirements:

Create your web application project as a File System project. Your solution folder

must contain all your project folders so that when you submit the solution folder all

necessary parts of your application are present. Your solution must include the source for all your projects; i.e. not just the DLLs for your business tier and data

access tier projects.

The web application project must use Forms-based authentication and

authorization.

Only members of the Librarian role must be able to access the web application.

(Use the membership and role management features of ASP.NET 2.0. Create a Librarian role and at least two Librarian users.)











Web Services (Phase 4) – XML, SOAP Messaging, Encryption, WSE 3.0 security. Requirements: Create a Web service that calls into either the business or data layer. Do

not re-write either layer. Simply have the service call in the appropriate layer. Update layers in the system to use the service as deemed appropriate. For

example, if the service layer called the business layer, then the user interface (i.e. the client) will need to change to use the Web service instead.

Make sure the Web service supports the Basic Profile. The service should use

Document/Literal formatting of the SOAP messages. Customize formatting of XML for some business types.

Employ WSE 3.0 security using Certificates. Signing, encryption and secure sessions are required.

Support previous functionality



Get Member from Library.asmx: Web Service Method …………….

using Microsoft.Web.Services3;

using SO.LibraryBusiness;

using System.Windows.Forms;

using System.Xml.Serialization;

using System.Data;

using System.Xml;

using System.Xml.Schema;

using System.IO;

using SO.LibraryEntities;

/// <summary>

/// webservice class

/// </summary>

[SoapDocumentService(Use = SoapBindingUse.Literal)]

[WebService(Description = "Basic Service", Namespace = "http://www.library.com/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

[Policy("SecurityPolicy")]

public class LibraryService : System.Web.Services.WebService

{

/// <summary>

///

/// </summary>

public LibraryService()

{

}

/// <summary>


/// </summary>

/// <param name="memberid"></param>

/// <returns></returns>

[WebMethod]

[XmlInclude(typeof(AdultMember)), XmlInclude(typeof(JuvenileMember))]

public Member GetMember(short memberid)

{

Member member = null;

BusinessLayer bl = new BusinessLayer();

try

{

member = bl.GetMember(memberid);

}

catch (LibraryException le)

{

string message = le.message;

//this constructor is called on Library exception because of message

format sent down to other layers

le = new LibraryException(le.LibraryErrorCode, ref message);

throw new SoapException(message, SoapException.ClientFaultCode,

Context.Request.Url.AbsoluteUri, le);

}

catch (Exception e)

{

throw new SoapException("Server Error", SoapException.ServerFaultCode,

Context.Request.Url.AbsoluteUri, e);

}

return member;

}

Add Adult.cs from AddAdult.aspx-ASP.NET Method modified for WSE security

protected void Button1_Click(object sender, EventArgs e)

{

proxy = new LibraryServiceWse();

proxy.SetPolicy("SecurityPolicy");

try

{

adult = new AdultMember();

adult.FirstName = TextBox1.Text;

adult.MiddleInitial = TextBox2.Text;

adult.LastName = TextBox3.Text;

adult.Street = TextBox4.Text;

adult.City = TextBox5.Text;

DateTime today = DateTime.Now;

adult.ExpirationDate = today.AddYears(1);

DropDownList1_SelectedIndexChanged(sender, e);

adult.State = DropDownList1.Text;

adult.ZipCode = TextBox6.Text;

adult.PhoneNumber = TextBox7.Text;

Member member = this.adult as Member;

member.AddMember = "Adult";

proxy.AddMember(ref member);

short MemberID = member.MemberNumber;

member = proxy.GetMember(MemberID);

member.ExpirationDate.ToShortDateString();


adult.MemberNumber = member.MemberNumber;

Response.Redirect(string.Format("GetMember.aspx?MemberID={0}",

adult.MemberNumber.ToString()));

}

catch (SoapException se)

{

Label4.Visible = true;

String message = "";

message = se.Message.Substring(30, 41);

MessageBox.Show(message);

Documents

Net Portfolio Shade