LocalBank Prosjektbeskrivelse INNHOLD MÅL... 2 STRUKTUR... 2 IMPLEMENTASJON AV ILOCALBANKREPOSITORY... 3 GUI... 4 EXCEPTION... 4 KODE... 4 NOEN KLASSER OG SPESIELLE EMNER SOM DE VISER... 5 KLASSE DIAGRAMMER... 6
MÅL Målet med mitt prosjekt har vært å utvikle kode som en trening i grunnleggende emner og ferdigheter innen C#. Dette bygger på de forutsettinger som faglærer, Øivind Øhra, la til grunn for leveranse tidlig i kurset. Det var ikke meningen at prosjektet skulle være systemutvikling der kreativitet, ide og programmets nytteverdi var sentralt, men at fokuset skulle være på å demonstrere sentrale emner i pensum. Det ble også lagt vekt på "Industrial Programming". Et av mine mål med prosjektet har derfor vært å bruke mye tid på dette som et verktøy for læring. Har brukt "Code Analysis" i Visual Studio jevnlig. Kravet som ble gitt var at vår kode skulle oppfylle "Microsoft Recommended Rules + Naming". Koden som nå leveres oppfyller dette kravet. Prøvde også å bruke "Microsoft All Rules", men dette gav ofte svært mange advarsler, og jeg syntes heller ikke at alle regler var like aktuelle for mitt prosjekt, men jeg har alikevel lært mye ved å gjøre oppslag på de advarslene som kom. En analyse av Code Metrics viser også at koden der oppfyller krav som ble gitt. En annen viktig målsetting for meg har vært å etterstrebe gjenbruk av kode. Dette har fått konsekvenser både i forhold til enkeltklasser, men også ved bruk av pattern og overordnet strukturen på løsningen. STRUKTUR Figuren under viser overordnet struktur. View og Controller blir ivaretatt av klassen MainForm som forholder seg til ILocalBankRepository. Klasser som implementerer ILocalBankRepository bestemmer selv hvordan data skal lagres, hva slags lagringsmedium som brukes og hvordan data hentes ut fra lager. Dette gir et tydelig skille mellom presentasjon og data.
IMPLEMENTASJON AV ILOCALBANKREPOSITORY Har gjort to forskjellige klasser som begge implementerer ILocalBankRepository. For å vise begge implementasjonene av Repository har jeg laget to setup-filer av den endelige løsningen slik at begge to kan prøves ut i praksis. Den ene, BinarySerializeRepository, bruker både binær serialisering og vanlige tekstfiler som data lager. Har i den sammenheng laget en static klasse, SerializeObject, som kan lagre objekter som binærfil og leser tilbake (se figur under). På grunn av gjenbruk er denne gjort generisk. BinarySerializeRepository benytter seg også av LINQ med Lambda uttrykk. Ved installasjon legges filene i brukerens mappe for programdata som betyr at bare den aktuelle brukeren har tilgang til disse. Dette hadde selvfølgelige ikke vært egnet for en reel bank applikasjon, men i tråd med overordnede mål for prosjektet. Den andre klassen (se fig. under), DatabaseConnectedRepository, benytter seg av database som lager, og forholder seg til klassen, DataLayer (i egen dll), som pakker inn en tilkobling til en database og utfører logikken knyttet til insert, update, select mm. Dette er gjort så generelt som mulig slik at DataLayer forholder seg til et tilkoblings navn som igjen gir tilkoblings strengen definert i applikasjonens konfigurasjonsfil (app.config). Den bruker en DbProviderFactory, som på bakgrunn av den aktuelle strengen etablerer tilkobling til riktig database. På denne måten kan DataLayer brukes med forskjellige typer databaser. Ved utviklingen av systemet brukte jeg to databaser, en med skolens MS Sql server på donau, og den andre med SQLEXPRESS lokalt på egen pc. DataLayer er også gjort IDisposable, slik at tilkoblingen til databasen kan kastes så fort den ikke lenger trengs, dvs. ved bruk av using. Etableringen av DataLayer gjør også at denne kan benyttes av andre applikasjoner som vil benytter seg av samme databasen. Alle parametere og return typer er derfor gjort generelle, og er uavhengig av datamodellen som er knyttet til dette spesielle prosjektet. Hadde plan om også å implementere DatabaseDisconnectedRepository som skulle bruke DataSet og data adapter(dbdataadapter) for å laste alle nødvendige data fra databasen og inn i data tabeller (DataTable). All midlertidige oppdateringer kunne da vært lagret til DataSet i minnet, og ved utlogging og lukking av programmet kunne jeg igjen brukt data adapter for å lagre de nye dataene til databasen. Fordelen med en slik løsningen er at det ikke er nødvendig med mange tilkoblinger til databasen. Fikk dessverre ikke tid til dette.
GUI Har ikke lagt vesentlig vekt på å utvikle/designe et bra grafisk bruker grensesnitt. Grafisk design er ikke min sterke side, og ville derfor heller bruke tid på de andre delene av prosjektet. Har allikevel prøvd å få noen av flaggene på plass, som ble nevnt av faglærer innledningsvis i kurset. Det grafiske grensesnittet er først og fremst for å kunne vise hvordan koden ellers fungerer. Den har tabbene Login, Sign Up, Payment, History og Admin. Payment og history er aktuelt for en kunde som er innlogget i banken, mens Admin er for ansatte i banken. Dette betyr at alle som er logget inn får tilgang til alle tabbene. Det at dette er gjort slik er også en følge av de overordnede mål, men vil også gjøre det enklere å teste hvordan de ulike delene fungerer. Har lagt vekt på å sikre innputt fra brukere, både ved å bruke kontrollere med filter, der dette er naturlig og ved å validere med hjelp av System.Windows.Forms.ErrorProvider. EXCEPTION Controller i MainForm tar imot alle mulige unntak som måtte komme ved å bruke catch(exception ex) Da denne forholder seg til interfacet ILocalBankRepository kan den ikke vite hva slags unntak som kan komme, da dette ville ha forutsatt kjennskap til implementasjon. Controler koden i MainForm er slik laget helt uavhengig av hvordan ILocalBankRepository er implementert. Alle annen kode (Library code), har metoder som kaster forskjellige former for unntak. Et unntak fra denne regelen er gjort i klassen DatabaseConnectedRepository som benytter seg av LocalBankDataLayer. Der er det gjort slik at DatabaseConnectedRepository fanger alle unntak som måtte komme når LocalBankDataLayer brukes. Disse unntakene er alle relaterte til transaksjon med en database. De fanges opp og så kaster metodene DatabaseTransactionException videre, der det sendes med en beskrivelse og en referanse til det indre unntaket som opprinnelig var årsaken. Vurderte også alternativt ikke fange opp unntak i denne klassen, men bare la alt bli kastet automatisk videre, men synes at den nåværende løsningen gjør det lettere å finne frem og debugge når unntak oppstår. Er allikevel noe usikker på hvordan dette forholder seg til " best practices". Har også vurdert logging av unntak. Dette er ikke en nødvendighet, men hadde vært en fordel ved debugging. Har ikke fått tid til å implementere dette. KODE Bortsett fra klassen ValidateEmail der innholdet i sin helhet er hentet fra MS sine hjelpesider, er all annen kode gjort selv. Koden som leveres vurderes å være velskrevet og godt dokumentert med xmltags. Dette kurset forutsatte levering av et individuelt prosjekt. Det er fordeler og ulemper med dette. Fordelen er mindre "byråkrati" og at den enkelte kan lettere utnytte tiden effektivt. Ulempen er at jeg ikke har kunnet dele koden og drøftinger underveis mere detaljert med en gruppe. Det kan være lett å se seg blind på egne løsninger, og feil kunne lettere vært oppdaget i en gruppe sammenheng. Vil allikevel si meg godt fornøyd med det resultatet som foreligger, og at jeg har nådd de målene som ble satt for prosjektet.
NOEN KLASSER OG SPESIELLE EMNER SOM DE VISER Klasse (r) Person, Customer, GoldCustomer, Employee Position, TypeOfBankAccount, StorageFormat mfl. Emner Arv, Implementering av IComparable og IComparable<Person> Operator overloading Enum DatabaseTransactionException, CannotSaveException, PasswordSizeException Egne unntaks klasser som arver Exception HashCode Bruk av SHA512CryptoServiceProvider og beregne hash kode. SerializeObject ILocalBankRepository Generic, Serialisering av objekter i binary og xml- format. Interface LocalBankDataLayer Sql med parametere (SqlParameter), object initializer, TransactionScoup, Implementering av IDisposable, ConnectionString og data provider factory BinarySerializeRepository ValidateEmail Lese fra vanlig tekstfil, Behandle filer med FileInfo, Hash tabell med Dictionary, LINQ med lamda uttrykk som også gjør bruk av operatorene som er overloada i Person, Sette riktig path ved bruk av Environment.GetFolderPath og Path.Combine Validere email med regulær uttrykk. MainForm Validere med hjelp av System.Windows.Forms.ErrorProvider, Bruk av kontrollere med filter, Events and delegates (automatisk definert i MainForm.Designer.cs)
KLASSE DIAGRAMMER FKSoft.Education.BankingDataModel
FKSoft.Education.Utilities FKSoft.Education.DataLayer
FKSoft.Education.Repository
FKSoft.Education.LocalBankView