Replacing the Old Data Transfer Object (DTO) of an Entity

Last week, I embarked on a task that involved replacing an old Data Transfer Object (DTO) for a particular entity, along with its associated address and contact DTOs. The process of updating the DTO also required me to adjust the mappings inside the services, since the old DTO used manual mapping, which I switched to using AutoMapper.

Additionally, as I proceeded with the replacement of the old DTO, I also diligently worked in debug mode, resolving errors in parallel. This approach allowed me to identify and rectify any issues that arose during the transition to the new DTOs. By addressing errors promptly, I ensured a smoother and more efficient integration of the updated DTOs into the existing codebase.

During the initial stages, I was eager to replace multiple DTOs, believing it would lead to a more refined codebase. However, Mr. Peter’s cautioned me from this approach. He advised me to focus solely on the current entity’s DTO, cautioning against unnecessary complexities that might arise from altering multiple DTOs simultaneously. This guidance had helped me maintain a more targeted and manageable scope for the task.

As I delved deeper into the task, I realized the opportunity to optimize my code further. A comprehensive review of my DTO codes enabled me to identify and remove unnecessary DTOs that I had initially considered adding. Eliminating these extraneous DTOs, which added little value to the overall structure, resulted in a more concise and easier-to-maintain codebase.

Last but not least, the changes in DTOs prompted me to reassess the services in the application. I transitioned the service that was being called directly accessing the database to the ones which utilize API connections.

Code Clean Up : Post-Code Review Session

Reflecting on the productive week that passed, I found myself engrossed in undertaking meticulously cleaning up the codebase following an extensive code review session with Mr. Peter. This session encompassed not only the application but also into the user interface. Mr. Peter thoroughly analyzes each and every line of code, ensuring its readability and maintainability for future utilization.

Throughout the session, Mr. Peter had taught me with valuable insights that enriched my understanding of the principles behind writing clean code. Initially, I had held the belief that it was best practice to encompass the entire usage of an entity within the create, update, and delete commands and queries. I had reasoned that by doing so, future developers would be relieved of the burden of defining or initializing them again. However, under Mr. Peter’s guidance, I realized the importance of minimizing the code to include only what is truly necessary, thereby reducing unnecessary clutter and improving overall code efficiency.

One specific aspect that came to light during the review process was the handling of query lists. It dawned on me that it was sufficient to define only the data that would be displayed on the screen or required to be passed to the user interface. This realization enabled me to streamline the code, eliminating any extraneous information and ensuring that it remains concise and purposeful.

As the week progressed and various code cleaning tasks were successfully accomplished, I approached the final assignment at hand, which is the replacement of old DTOs with newer versions. However, in the midst of this process, I encountered a minor setback. I mistakenly attempted to modify a specific element that Mr. Peter promptly clarified that it should not be altered at this stage. He explained that making such changes would necessitate significant code modifications, better suited for future endeavors.

Despite this slight misstep, I am grateful for the wealth of knowledge gained during the code review session. It truly cultivated a deeper understanding of the importance of code cleanliness, readability, and maintainability.

Add-Migration and Code Reviews

Last week, I had the opportunity to apply my knowledge on EF Core’s Add-Migration command. Add-Migration is a command provided by Entity Framework Core (EF Core) that allows a developer to create a new migration based on the changes made to database context. People use Add-Migration when they need to update their database schema to reflect changes made in their application’s data model. The reason I was told to use Add-migration was because I needed to add a new data field into the data model for an entity.

To my surprise, using Add-Migration turned out to be much easier than I anticipated. I took a cue from the previous commit and used it as a reference, ensuring I was on the right track. I also sought clarification from Mr. Peter to verify my understanding of the steps involved. First things first, I initialized the new data field in all the necessary commands: create, update, delete, and query. It was crucial to ensure that the new field was properly integrated into all aspects of data manipulation. Consequently, I diligently updated the tests for create, update, delete, and query until each test passed successfully. 

Moving on to the user interface (UI), I introduced an interface for the new data field, making sure to bind it correctly. It was important to create a seamless connection between the UI and the underlying application logic. With the interface in place, I proceeded to establish the mapping connection both at the application level and within the user interface, ensuring the new field’s values flowed smoothly between the two.

Additionally, I paid attention to the configuration entity responsible for handling its connection. This configuration entity played a vital role in configuring the entity’s properties, relationships, and constraints using EF Core’s Fluent API. I made sure to incorporate the new data field into this entity’s configuration, ensuring its proper representation within the database schema.

With everything set and ready to go, I opened up the Package Manager Console and eagerly executed the command ‘Add-Migration <the migration name>’ and then applied the migration using the ‘Update-Database’ command. This command executed the migration script, effectively creating a new data field table in the database with all the necessary changes incorporated.

Later that week, I had a helpful code review session with Mr. Peter. He carefully reviewed my code and pointed out some mistakes I had made. He also gave me valuable advice on how to write better code. One important lesson I learned from Mr. Peter is the significance of paying attention to every detail when writing code. He stressed that each line of code matters and should be written with care. It’s crucial to write code that is easy to read, understand, and maintain. It became evident that thoroughness and precision in coding were key factors in ensuring the reliability and efficiency of our applications. In a nutshell, my journey with EF Core’s Add-Migration command and the insightful code review session have been immensely valuable and I’m excited to continue applying these lessons in my future coding endeavors.

Optimizing User Interface

In my previous blog post, I shared the difficulties I encountered while working on the contact management functionality. Specifically, I was facing challenges in enabling the ability to delete and update contacts in the contact list. Initially, my assumption was that the issue lay within the code responsible for updating the data in the database. My thoughts were that I might be missing a few code that is crucial for updating to the database. 

After Mr. Peter reviewed the code, it was discovered that the main reason for the problem was the incorrect usage of a specific function. Specifically, instead of using the “Get contact by Id” function from the entity service, I had been using the “Read contact by Id” function. This incorrect usage of the function was causing the problem I was experiencing. In cases where modifications to the database were required, it was crucial to use the “Get” function. The key difference between the two functions was that the “Read” function utilized the “.AsNoTracking” feature, which instructed the code not to track any changes made. In my specific scenario, where updates and deletions needed to be reflected in the database, employing the “Get” function was imperative.

Next, I proceeded to the next task on my agenda, which focused on optimizing the user interface. The first part of this endeavor involved making subtle but impactful modifications to the contact list interface. I paid close attention to the area where users added new contacts, ensuring that the process was intuitive and streamlined.

The following task is to make the UI non-editable while users are in view mode. This aspect allowed me to implement and gain a better understanding of what data binding can do. I used binding to change the IsReadOnly property of TextBox elements based on their current mode. When in view mode, I set IsReadOnly to true, effectively preventing users from making any inadvertent changes. Conversely, in edit mode, I set IsReadOnly to false, empowering users to modify the necessary information.

During this process, Mr. Peter also enlightened me about another valuable feature related to buttons. Specifically, he shared about how buttons could be dynamically hidden in certain scenarios. This feature proved particularly useful in scenarios where certain buttons were unnecessary or irrelevant, allowing for a cleaner and more focused user experience.