Talk:Isearve - Revision history

Mkeerus: Undo revision 117595 by Mkeerus (talk)

2017-02-02T05:48:41Z

Undo revision 117595 by Mkeerus (talk)

← Older revision		Revision as of 08:48, 2 February 2017
Line 60:		Line 60:
	* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.		* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.

	Selleks, et rakendust päriselt kasutada, võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti.		Lisaks võiks saada ettevõtte enda andmeid ka muuta, kui näiteks aadress muutub ja tihti on ettevõtetel mitu pangakontot, aga hetkel on võimalik kasutada ainult ühte. Selleks, et rakendust päriselt kasutada, võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti.

	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

Mkeerus: /* Retsensioon lõpptootele */

2017-02-02T05:42:03Z

Retsensioon lõpptootele

← Older revision		Revision as of 08:42, 2 February 2017
Line 60:		Line 60:
	* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.		* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.

	~~Lisaks võiks saada ettevõtte enda andmeid ka muuta, kui näiteks aadress muutub ja tihti on ettevõtetel mitu pangakontot, aga hetkel on võimalik kasutada ainult ühte.~~ Selleks, et rakendust päriselt kasutada, võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti.		Selleks, et rakendust päriselt kasutada, võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti.

	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

Ejogi: /* Retsensioon lõpptootele */

2017-02-01T21:15:34Z

Retsensioon lõpptootele

← Older revision		Revision as of 00:15, 2 February 2017
Line 64:		Line 64:
	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

	'''Rakenduse kood''' on üldiselt arusaadav, kommenteeritud, loetavalt vormindatud ja jagatud loogiliselt kihtidesse: BO, service, viewmodels, views. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM", mida tundub, et tegelikult ei kasutatagi. Meie arvates peaks INotify olema siiski ViewModeli ~~tasendil~~, sest on vaatega seotud. Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus. InvoiceBO-s olevad getterid paistavad kohati sisaldavat osi, mis kuuluvad pigem äriloogika alla. InvoiceBO sees ridadel 82-106 property sees on tehtud andmbaasist päring, kuid meie arvates peaks jääma andmebaasist päringud service'isse.		'''Rakenduse kood''' on üldiselt arusaadav, kommenteeritud, loetavalt vormindatud ja jagatud loogiliselt kihtidesse: BO, service, viewmodels, views. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM", mida tundub, et tegelikult ei kasutatagi. Meie arvates peaks INotify olema siiski ViewModeli tasandil, sest on vaatega seotud. Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus. InvoiceBO-s olevad getterid paistavad kohati sisaldavat osi, mis kuuluvad pigem äriloogika alla. InvoiceBO sees ridadel 82-106 property sees on tehtud andmbaasist päring, kuid meie arvates peaks jääma andmebaasist päringud service'isse.
	Positiivse poole pealt tooks välja, et võimalikud andmebaasi exceptionid paistavad ilusti Service'i poolel try/catchidega kontrolli all olevat.		Positiivse poole pealt tooks välja, et võimalikud andmebaasi exceptionid paistavad ilusti Service'i poolel try/catchidega kontrolli all olevat.

Ejogi: /* Retsensioon lõpptootele */

2017-02-01T21:14:55Z

Retsensioon lõpptootele

← Older revision		Revision as of 00:14, 2 February 2017
Line 64:		Line 64:
	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

	'''Rakenduse kood''' on üldiselt arusaadav, kommenteeritud, loetavalt vormindatud ja jagatud loogiliselt kihtidesse: BO, service, viewmodels, views. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM", mida tundub, et tegelikult ei kasutatagi. Meie arvates peaks INotify olema siiski ViewModeli tasendil, sest on vaatega seotud. Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus.		'''Rakenduse kood''' on üldiselt arusaadav, kommenteeritud, loetavalt vormindatud ja jagatud loogiliselt kihtidesse: BO, service, viewmodels, views. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM", mida tundub, et tegelikult ei kasutatagi. Meie arvates peaks INotify olema siiski ViewModeli tasendil, sest on vaatega seotud. Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus. InvoiceBO-s olevad getterid paistavad kohati sisaldavat osi, mis kuuluvad pigem äriloogika alla. InvoiceBO sees ridadel 82-106 property sees on tehtud andmbaasist päring, kuid meie arvates peaks jääma andmebaasist päringud service'isse.
	InvoiceBO sees ridadel 82-106 property sees on tehtud andmbaasist päring, kuid meie arvates peaks jääma andmebaasist päringud service'isse.
	Positiivse poole pealt tooks välja, et võimalikud andmebaasi exceptionid paistavad ilusti Service'i poolel try/catchidega kontrolli all olevat.		Positiivse poole pealt tooks välja, et võimalikud andmebaasi exceptionid paistavad ilusti Service'i poolel try/catchidega kontrolli all olevat.

Ejogi: /* Retsensioon lõpptootele */

2017-02-01T21:10:46Z

Retsensioon lõpptootele

← Older revision		Revision as of 00:10, 2 February 2017
Line 60:		Line 60:
	* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.		* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.

	Lisaks võiks saada ettevõtte enda andmeid ka muuta, kui näiteks aadress muutub ja tihti on ettevõtetel mitu pangakontot, aga hetkel on võimalik kasutada ainult ühte. Selleks, et rakendust päriselt kasutada võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti.		Lisaks võiks saada ettevõtte enda andmeid ka muuta, kui näiteks aadress muutub ja tihti on ettevõtetel mitu pangakontot, aga hetkel on võimalik kasutada ainult ühte. Selleks, et rakendust päriselt kasutada, võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti.

	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

Ejogi: /* Retsensioon lõpptootele */

2017-02-01T21:06:27Z

Retsensioon lõpptootele

← Older revision		Revision as of 00:06, 2 February 2017
Line 45:		Line 45:
	'''Rakenduse idee''' on väga hea. Tegemist on töölauarakendusega, milles on võimalik koostada arveid ning hoiustada oma partnereid ja neile koostatud arveid.		'''Rakenduse idee''' on väga hea. Tegemist on töölauarakendusega, milles on võimalik koostada arveid ning hoiustada oma partnereid ja neile koostatud arveid.

	'''Funktsionaalsus''' on antud rakenduse jaoks sobiv. Loodud funktsionaalsus töötab~~, kuid selleks, et rakendus oleks päriselt ka kasutatav, vajab see natuke lisaarendust, aga suur töö on juba tehtud~~. Toome välja mõned tähelepanekud, mis testimisel tekkisid.		'''Funktsionaalsus''' on antud rakenduse jaoks sobiv. Loodud funktsionaalsus töötab. Toome välja mõned tähelepanekud, mis testimisel tekkisid. Välja toodud tähelepanekud ei ole kindlasti vead, need on välja toodud ideede andmiseks ja ei ole kahtlust, et meeskond isearve nende realiseerimisega hätta jääks.

	Partnerite sisestamine:		Partnerite sisestamine:
Line 60:		Line 60:
	* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.		* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.

	Lisaks võiks saada ettevõtte enda andmeid ka muuta, kui näiteks aadress muutub ja tihti on ettevõtetel mitu pangakontot, aga hetkel on võimalik kasutada ainult ühte. Selleks, et rakendust päriselt kasutada võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti~~. Välja toodud tähelepanekud ei ole kindlasti vead, need on välja toodud ideede andmiseks ja ei ole kahtlust, et meeskond isearve nende realiseerimisega hätta jääks~~.		Lisaks võiks saada ettevõtte enda andmeid ka muuta, kui näiteks aadress muutub ja tihti on ettevõtetel mitu pangakontot, aga hetkel on võimalik kasutada ainult ühte. Selleks, et rakendust päriselt kasutada võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti.

	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

	'''Rakenduse kood''' on üldiselt arusaadav, kommenteeritud ja loetavalt vormindatud. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM", mida tundub, et tegelikult ei kasutatagi. Meie arvates peaks INotify olema siiski ViewModeli tasendil, sest on vaatega seotud. Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus.		'''Rakenduse kood''' on üldiselt arusaadav, kommenteeritud, loetavalt vormindatud ja jagatud loogiliselt kihtidesse: BO, service, viewmodels, views. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM", mida tundub, et tegelikult ei kasutatagi. Meie arvates peaks INotify olema siiski ViewModeli tasendil, sest on vaatega seotud. Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus.
	InvoiceBO sees ridadel 82-106 property sees on tehtud andmbaasist päring, kuid meie arvates peaks jääma andmebaasist päringud service'isse.		InvoiceBO sees ridadel 82-106 property sees on tehtud andmbaasist päring, kuid meie arvates peaks jääma andmebaasist päringud service'isse.
	Positiivse poole pealt tooks välja, et võimalikud andmebaasi exceptionid paistavad ilusti Service'i poolel try/catchidega kontrolli all olevat.		Positiivse poole pealt tooks välja, et võimalikud andmebaasi exceptionid paistavad ilusti Service'i poolel try/catchidega kontrolli all olevat.

Ejogi: /* Retsensioon lõpptootele */

2017-02-01T20:33:36Z

Retsensioon lõpptootele

← Older revision		Revision as of 23:33, 1 February 2017
Line 60:		Line 60:
	* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.		* Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.

	Lisaks võiks saada ettevõtte enda andmeid ka muuta, kui näiteks aadress muutub ja tihti on ettevõtetel mitu pangakontot, aga hetkel on võimalik kasutada ainult ühte. Selleks, et rakendust päriselt kasutada võiks ~~funktsionaaluse~~ poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti. Välja toodud tähelepanekud ei ole kindlasti vead, need on välja toodud ideede andmiseks ja ei ole kahtlust, et meeskond isearve nende realiseerimisega hätta jääks.		Lisaks võiks saada ettevõtte enda andmeid ka muuta, kui näiteks aadress muutub ja tihti on ettevõtetel mitu pangakontot, aga hetkel on võimalik kasutada ainult ühte. Selleks, et rakendust päriselt kasutada võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti. Välja toodud tähelepanekud ei ole kindlasti vead, need on välja toodud ideede andmiseks ja ei ole kahtlust, et meeskond isearve nende realiseerimisega hätta jääks.

	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

Ejogi: /* Retsensioon lõpptootele */

2017-02-01T20:31:08Z

Retsensioon lõpptootele

← Older revision		Revision as of 23:31, 1 February 2017
Line 64:		Line 64:
	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

	'''Rakenduse kood''' on arusaadav, kommenteeritud ja loetavalt vormindatud. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM". Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus.		'''Rakenduse kood''' on üldiselt arusaadav, kommenteeritud ja loetavalt vormindatud. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM", mida tundub, et tegelikult ei kasutatagi. Meie arvates peaks INotify olema siiski ViewModeli tasendil, sest on vaatega seotud. Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus.
			InvoiceBO sees ridadel 82-106 property sees on tehtud andmbaasist päring, kuid meie arvates peaks jääma andmebaasist päringud service'isse.
			Positiivse poole pealt tooks välja, et võimalikud andmebaasi exceptionid paistavad ilusti Service'i poolel try/catchidega kontrolli all olevat.

	'''Kokkuvõtteks''' on suur osa 'must-have' funktsionaalsusest loodud ja tundub, et ka selle aine raames vajalikud oskused omandatud.		'''Kokkuvõtteks''' on suur osa 'must-have' funktsionaalsusest loodud ja tundub, et ka selle aine raames vajalikud oskused omandatud.

Ejogi: /* Retsensioon lõpptootele */

2017-02-01T19:48:53Z

Retsensioon lõpptootele

← Older revision		Revision as of 22:48, 1 February 2017
Line 64:		Line 64:
	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

	'''Rakenduse kood''' on arusaadav, kommenteeritud ja loetavalt vormindatud. Meis tekitab segadust, SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM". Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus.		'''Rakenduse kood''' on arusaadav, kommenteeritud ja loetavalt vormindatud. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM". Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus.

	'''Kokkuvõtteks''' on suur osa 'must-have' funktsionaalsusest loodud ja tundub, et ka selle aine raames vajalikud oskused omandatud.		'''Kokkuvõtteks''' on suur osa 'must-have' funktsionaalsusest loodud ja tundub, et ka selle aine raames vajalikud oskused omandatud.

Ejogi: /* Retsensioon lõpptootele */

2017-02-01T19:48:32Z

Retsensioon lõpptootele

← Older revision		Revision as of 22:48, 1 February 2017
Line 64:		Line 64:
	Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.		Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

	'''Rakenduse kood''' on arusaadav, kommenteeritud ja loetavalt vormindatud.		'''Rakenduse kood''' on arusaadav, kommenteeritud ja loetavalt vormindatud. Meis tekitab segadust, SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM". Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus.

	'''Kokkuvõtteks''' on suur osa 'must-have' funktsionaalsusest loodud ja tundub, et ka selle aine raames vajalikud oskused omandatud.		'''Kokkuvõtteks''' on suur osa 'must-have' funktsionaalsusest loodud ja tundub, et ka selle aine raames vajalikud oskused omandatud.