This week I have continued to modify the customer feature. Mr. Peter had instructed me to add another table address. The customer table in the customer feature will have some relationships with the address table. Each customer will have many addresses. In addition, each customer will also have default address. Furthermore, each address can only belong to one customer. Mr. Peter continued by pointing out that I had made a mistake in the customer table, as I had accidentally used the plural word when referring to a single field.<\/p>\n\n\n\n
First, I changed the column name from a plural term to a singular word in the customer table. In addition, I eliminated the extraneous column that was appended to the address table. In the customer table, I have further included the addresses. The return type of address will be present in these two attributes. In the meantime, an additional feature has been added: customer addresses. This attribute will hold a list of addresses that are specific to a given client. Next, I created the address table and included the attributes needed for the address table. I have also included the customer attribute, that has the type of customer since I need to know which address belonged to which customer.\u00a0<\/p>\n\n\n\n
After creating the new address table and implementing the relationships between the customer and address table in the core project,\u00a0 I will need to change each of the customer features, for example: list query, and others. The relationship I have built in the core project must be implemented in all customer features. So, I started to modify the id query. I’ll start by adding the attribute that this query will display after it is implemented. I then have to change this query’s dapper implementation. This is due to the fact that the earlier iteration of the dapper implementation only had a basic query method for retrieving data from the customer table. I must, however, query the customer and address tables for the time being. As a result, I must modify the dapper implementation such that these two tables have a one-to-many relationship. This is the trickiest part since I have to write a lot of additional code to make sure this stuff works.\u00a0<\/p>\n\n\n\n
After making various changes to the dapper implementation, I can now execute the query correctly and test it multiple times. I can therefore keep changing other client features. After modifying all customer features, Mr. Peter advised me that there are several improvements that I can do for the customer features, such as adding validation when creating or updating the customer, simplifying query and others. So, I will try to improve the customer feature next week.<\/p>\n","protected":false},"excerpt":{"rendered":"
This week I have continued to modify the customer feature. Mr. Peter had instructed me to add another table address. The customer table in the customer feature will have some relationships with the address table. Each customer will have many addresses. In addition, each customer will also have default address. Furthermore, each address can only … <\/p>\n