Last Week!

16 weeks have passed since I’ve first written my first blog.

Throughout the 4 months, I’ve learnt a lot. I started with zero knowledge about MVVM and TDD, but after 16 weeks I can proudly say that I’ve at least understood the basic concepts of how they work.

For the last week, I implemented the logic of displaying a dialogue box when a PurchaseInvoice cannot be created due to an invoice previously created for the GoodsReceived.

When trying to navigate through different pages in the codes, event aggregators are used, because we have changed the way the module is used to be tabs, hence, we need to specify the exact tab that we want to be navigated to when we press a button or a call function.

I have also fixed few functions that I realised where not working well by checking the tests written for the last time.

Lastly, I would like to thank Tong Hin for giving me the opportunity to conduct my internship with them, especially my supervisor Mr. Peter, for having the patience with me, guiding and instructing me throughout my training.

I would like to thank everyone who has worked and ensured that my time at Tong Hin was smooth and memorable.

Thank you once again.

Integration and checking of errors

For the past week I have worked on integration tests as well as checking the creation of modules for errors.

The checking involved checking whether a Tax, Supplier, PurchaseOrder, GoodsReceived and PurchaseInvoice can be created successfully without any errors, as well as checking the content inserted into the views.

When using tab navigation, the tests created will not be able to mock the NavigationContext, which will always lead the test being run to use the default value instead of navigating to the wanted and requested view of PurchaseInvoice, either from PurchaseOrder or GoodsReceived. Hence, to solve this problem another method is creating which includes parameters that carry the designated values, which will then be called from the method which includes the NavigationContext.

Next, when adding LineItems using the Add button in PurchaseInvoice from GoodsReceived, only 1 line item is updated and the errors lied because I did not map the LineItemId.

Lastly, I started working on displaying a dialogue box when a PurchaseInvoice already exists. The test has been created with the help of my supervisor.

See you all on my last blog Next week 🙂

Navigation Concept and More of Errors Solving

Since I have completed the PurchaseInvoice module, I needed to fix errors that are present and check the codes again.

Firstly, I started by checking the property isAllPurchaseInvoiceReceived, by checking from the UI to see if the property gets flagged when all invoices are received, and hence after checking, I had to change the logical property of quantity to ensure that if a quantity more than ordered is received the property, then it will not be flagged or be true in its boolean expression.

Next, another error which was found is that when a user creates a GoodsReceive and PurchaseInvoice from PurchaseOrder, the GoodsReceive can afterwards be used when creating a PurchaseInvoice from GoodsReceive, which will result in having an Invoice with the same quantity number received but different cost which is a conflict. To solve the error, the relationship between GoodsReceive and PurchaseInvoice was adjusted by using the EF Core concept of relationships One-to-One by defining the relationship in the config file.

I have also pulled codes from Git and adjusted few parts, that resulted in the project to be using tabs navigation concept instead of dialogues. Such that a user, can have multiple tabs opened at the same time and each is independent on the other. At the same time, this current navigation is more user friendly.

WPF allows the concept of using a ViewModel without getting access to its View. In other words, it loads the codes and knowledge from a ViewModel without taking the view into consideration.

Another information I learnt from GitHub was when pulling if we are not present in the designated branch then we won’t be able to see the changes that have been to the codes. As pulling without being in the branch does not grant us access to the changes made.

See you all next week 🙂

Fixing errors and bugs in the project module

Since I have completed the purchase invoice from both purchase order and goods received, I spent the week checking the codes, and finding bugs to be solved to ensure that the module runs as intended without any problems.

I also had problems with the quantity mapping, as the total quantity being mapped in purchase invoice from purchase order is not the same as the total quantity from purchase invoice from goods received line item. The error was because I was initially reading the quantity from purchase invoice line item and goods receive line item instead of reading from the same entity which is goods receive line item. Due to this, different total quantity was being displayed in the UI.

Next, I wrote integration tests for purchase invoice from purchase order and goods received. The tests included creating new purchase invoices, and loading the list of purchase invoices, as well as viewing the individual purchase invoices.

When writing tests, mocks are being used. Mock uses the concept of testing a unit of code which depends on a group of other codes, such that the code will be tested even though its dependent codes are not written or contain bugs. In this case, mocks act as a platform which provides the test with its all needed requirements and environment to ensure that it works and pass as intended.

I also learnt how to resolve issues in Git. Meaning that once an issue is assigned to a person, and it is solved, to resolve the issue on Git, comments such as Fix, Close and Resolve are written alongside to the issue number created, as well as the codes need to be pushed so the changes can be viewed and tracked.

See you all next week 🙂

Working more on the project structure

Continuing fixing errors from the pull and merging of codes, a lot of changes have been made to ensure that the codes compile and align with the new project structure.

The tests that have been written previously for Purchase Order and Goods Received were in need of changing and fixing, as the code structure have changed, the tests also got affected, as a result, the test bases were in need to be checked and fixed, because when debugging the tests to see where the error lies, the debugger does not run through the test, meaning it does not go into the test method environment indicating that the error lies in the test base.

Another thing is the save changes during initialization. Save changes is set to true without using the newly added save changes which is equipped with audit, because we are just initialization and setting the environment, thus, we do not need to audit or check and keep track to see who has made changes to the codes.
When writing tests, the Linq property Single() cannot be used for entities that are equipped with more than one element, as in this case we are trying to assume that entity has only one value which is not true. Thus First() is used when we want to retrieve one element only.

After the fixing and refactoring of codes, the views of the purchase invoice module were not being displayed, due to 2 main reasons which were that the Region Manager for purchase invoice was not added, as well as I mistakenly created a new view and removed the prism:ViewModelLocator.AutoWireViewModel="True" which resulted in the pages not being attached to each other and hence cannot be redirected once requested.

In the view models, often the properties are assigned with two access modifiers. Properties with private access modifiers when used do not make any changes to the User interface, on the other hand, properties with public as their access modifiers when changed or used will make changes on the user interface.

These are the major things that have been learnt the past week. See you all next week 🙂

New changes added to the project structure

The week started by completing the conversion of parameters files into events by using the enum class.

Next, I created multiple tests for the my transaction function, which creates a new purchase invoice based on different services.

Unfortunately, I had an error with the previously created tested for my transaction function, as the SupplierId could not get updated, it was null, but I couldn’t find the way to solve it, only to realize later on with the help of my supervisor, that I did not initialize the SupplierId in the tests, because I thought by just initializing and getting access to the whole entity, it will automatically assign the SupplierId, which was obviously wrong and made the tests created fail.

I then started analyzing the aggregates in the project, and found myself not understanding the concept behind the many-to-many relationship between some entities in the project. With further discussion, the relationship was converted from many-to-many to one-to-many relationship, and due to this many changes were needed to made.

Among the changes done to the files, were to change the complete function in the transaction for the purpose of auditing. As well as, EventName, Time and UserId has been added to the service functions, for auditing purposes as well, such that the when changes have been made, the person who made the change, along with the time and the change made can be tracked. Thus, by making these changes new parameters have been added to the methods.

Previously, the services and repositories interface used to implement the IDisposable interface, but now a new interface has been created that implements the complete, commit and rollback functions, not forgetting that this new interface implements the IDisposable interface as well.

Lastly, an important thing I learnt from Git, is that Pull merges two coding files together, in other words, it adds the changes that have been in both files and merges them into one. Push, on the other hand, add the branch into the project but does not merge it.

That’s all, see you all next week 🙂

UI Week!

Here’s a quick summary of what I did last week.

I worked on the user interface of purchase invoice, a lot was learned when it comes to handling, implementing and writing codes.

I read about IQueryable and IEnumerable properties. Both are very similar and at the same time they differ in many ways that make them distinct. Such that the first runs against queryable collection, while the latter runs in memory location. Another difference lies on the execution of the select query property, IQueryable executes the logic of the select on the database, thus less work is needed and is performed fast. On the other hand, IEnumerable executes the select query logic on the client side, which requires more work and hence is slow. IQueryable is inherited from the IEnumerable class.

I have also read about the mapping function which is available in the EF core. The auto-mapper function maps only one object to another, which is not an efficient way of mapping properties, thus using methods which acts as a mapper is a more efficient and reliable.

Thus, I managed to display content on the purchase invoice, as well as view purchase order number for each invoice.

Mostly, the coding work revolved around the view, viewModel, service, wrapper and wrapperServices and etc.

See you all next week 🙂

Implementation of new functions and classes

This week is also about UI.

I created a new button to separate the purchaseInvoice different options. One which focuses on purchaseInvoice from purchaseOrder and another from GoodsReceived.

purchaseInvoice from purchaseOrder creation is created completely in other words creating a new purchaseInvoice and GoodsReceived. However, when updating the tests created previously, the tests failed due to the supplier entity and supplierId being 0.

At first, I couldn’t understand the reason why it is zero, but with the help of my supervisor, I found out that my mistake was that I did not include the supplierId and entity nor did I map it to the purchaseInvoice.

I also created an integration test for purchase invoice from purchase order. This test is more into testing the UI of the system. Checking whether when the intended button are clicked they perform and function as required.

I was also exposed to adding relationships in the database. I mean, when I set relationships in the entities file, some relationship will get ignored or confused by the entity framework if not fixed and identified properly in the Config files. Such that relationships such as one-to-many and many-to-many need to be written in the config files, along with their foreign keys, to ensure that the relationship is properly understood by the framework.

The main purpose behind using the Linq properties Include and ThenInclude is to ensure that the wanted properties to be retrieved are not null.

Lastly, I have refactored the codes in my module, such that all event functions are placed in the Events folder instead of Parameters folder.

When using the functions in the Events folder, I was introduced to using the enum, which is a special class that groups a group of related variables together. These, variables can be separated by a comma as follows:

public enum Level () { Low, Medium, High, }

The items in enum can be later on used or retrieved by using dot operation to get access to the enum class then the item.

More into UI!

I was still working on the user interface for the past week as well.

I have as well updated the tests created previously by adding a new GoodsReceive. Such that the first scenarios of my major task is that when a user searches for a supplier from a purchase order, at the same time while creating a purchase invoice a goods received is created as well is almost 70% complete.

I also got to know that when retrieving properties or entities in EF core, we cannot mix Tracking and NoTracking, such that AsNoTracking() functions are used with method headers that contain the word “Read” as the method is only reading values from the database without getting tracked whether these values have been changed or not.

Likewise, method headers with Get are used when we want to track values in the database.

Wrappers are always involved with work that has to deal with the user interface. Meanwhile, services are involved with database work.

The Linq function Select() return a collection of items or elements, while, First() returns the first element that satisfies the condition.

See you all next week 🙂

More into coding

Last week was a merge of creating tests and starting UI codes.

After so long, I was done with writing tests. I had a better understanding of how tests work, and refactoring codes as well. Moreover, I was exposed to not writing hard coded codes.

After 7 weeks, I can say that I have learnt a lot about TDD and EF Core, which is something I was not exposed to during my studies and this is something that would definitely benefit me.

Collection and Lists might sound the same, but collections are preferred over lists due to their ability to group outputs. In other words, List does not provide the feature of grouping.

For the past 3 years, I had the idea that the difference between void and static functions was related to having returns.

Little did I know that the static functions and variables are like global variables that can be used across the files, and when a method is static all its members should occupy the word “static” as well.

I have also read about bindable base which is an implementation of INotifyPropertyChanged interface in C#.