Implementing an API Layer Within the View Model

Over the past two weeks, I have been thoroughly exploring the user interface. During the previous week, I was assigned a task by Mr. Peter to modify the way our system interacts with the database within the MVVM architecture. Instead of establishing a direct connection to the database, he has instructed me to implement an API layer within the view models. This API layer will not only facilitate entity creation but also handle updates and deletions of entities.

To begin, I recognized the need for a new Dto Wrapper that would facilitate the interaction between our application and the API when I was studying the existing code provided by Mr Peter. This wrapper encapsulates the necessary data and functionality required for the saving process. With careful consideration, I designed and implemented the Dto Wrapper to seamlessly integrate with the existing codebase.

Next, I established a new service acting as an interface for API calls. This service handles the communication between our application and the API layer. By abstracting the API interaction into a separate service, a cleaner and more modular code is achieved, improving maintainability and testability. With the groundwork laid, I delved into the entity view model, meticulously analyzing the sections that needed modification to transition it into an API layer. Then, in the view model’s constructor, I initialized the interface services, AutoMapper, and dispatcher, setting the stage for seamless integration with the API layer.

In the case where the user pressed ‘Save’, a dialog is executed. This visually indicates the ongoing progress of the data-saving process, enhancing the user experience. Within this execution, the SaveRoutineAsync method is awaited to ensure the data is saved successfully. Based on the outcome of the saving process, different events are published using the Event Aggregator pattern. If the save operation completes successfully, an event is published with the corresponding parameters, such as the Guid, the mode set to SaveComplete, and an Id was retrieved from the Dto wrapper. 

In addition to the progress mentioned above, I also incorporated the entity’s account details, such as its ID, type, and code. I noticed that this data was also required on the entity’s detailed UI page that I was working on. To address this, I added the account details to the entity profile and ensured that the necessary CRUD operations were implemented at the backend.

Furthermore, I successfully implemented the API functionality, allowing for the correct display and seamless saving and updating of all the data. This accomplishment marked a significant milestone in the integration process for the working entity, as the application was now fully utilizing the power of the API to retrieve and manipulate data effectively.

However, as the week came to a close, I encountered a challenge related to the deletion functionality in the entity’s contact list. It appeared that the deletion process was not functioning as expected. This issue will be my focus for the upcoming week, as I aim to investigate and rectify the problem within the view model. By addressing this issue, I will ensure that the deletion of contacts from the entity’s contact list functions smoothly and seamlessly.

Leave a Reply