Month: June 2023

Last week was quite eventful for me as I took on the task of adding a new data field to an entity in my project. Specifically, I wanted to focus on the address of the entity within the entity’s details. Fortunately, the entity’s address was already present in the user interface (UI), so my main objective was to ensure that the address entered by the user was being handled accurately when interacting with the database and when passing it back to the front-end.

To accomplish this, I started by working on the backend. Using the powerful CQRS pattern, I initialized the entity’s address within the create and update commands, as well as the get by ID query. Additionally, I established the necessary mapping connection within the entity’s profile. This backend setup was crucial in ensuring smooth data flow.

Moving on to the UI, I wanted to make the user experience seamless and error-free. I began by initializing the address within the entity’s DTO wrapper and the corresponding list. Furthermore, I ensured that the mapping connection was properly configured within the entity’s profile. I also took the opportunity to improvise and modify the existing state management and to facilitate the interaction of the address in the entity’s detail view model. This view model is responsible for presenting the entity’s detailed information on the frontend.

Eager to see the results, I ran the application and dove into the debugging phase. Initially, things seemed to be progressing well. However, I soon encountered a bug that left me puzzled about its origin. Thankfully, Mr. Peter suggested that I check the entity’s tests to determine if they were passing. It turned out that a few tests were unsuccessful, which gave me valuable insights and a new starting point to resolve the bug. Mr Peter also emphasized the significance of functional tests, not only that it can help me for bug resolution, but also for long-term benefits in future development efforts.

As the week drew to a close, there was one lingering issue that I had not been able to resolve. Whenever I attempted to remove contacts from the contact list, the database failed to update accordingly. This resulted in the unchanged and unremoved contacts persisting in the database. It was a perplexing problem, but one that I was determined to tackle head-on. This week, my primary focus will be on debugging and resolving this issue, with the goal of resolving it within a day.

In summary, last week was filled with progress and challenges. I successfully integrated a new data field into the entity, ensuring that user-entered addresses were handled correctly. While I faced some unexpected bugs, the process of debugging and testing has provided me with valuable insights for moving forward.

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.

Last week, I had the opportunity to explore the user interface of sandbox project. Mr. Peter assigned me a few tasks, one of which was to add a filter to an entity list in the view model, incorporating search functionality and page numbers. As usual, he provided me with a code example of a complete view model to learn from, which was very helpful.

From studying the example view model, I identified several important aspects that I should pay attention to. These include dependency injection, data binding, mapping, working with a DataGrid, and handling events.

Dependency injection, as I mentioned last week, is a crucial concept in the MVVM architecture. It promotes loose coupling, enhances maintainability, and facilitates testing. In the context of the view model, dependency injection involves providing the required dependencies (such as services, data repositories, or other objects) to the view model from an external source, typically through constructor parameters.

The use of a datagrid in the view model suggests that the view presents tabular data or a grid-like structure. A datagrid is a UI control that enables the display and manipulation of tabular data, typically in the form of rows and columns. The view model would provide the necessary data and commands to populate and interact with the datagrid in the view.

Data binding is another essential aspect of MVVM. It establishes a connection between the view and the view model, allowing for seamless synchronization of data changes between the two. With data binding, it bind properties of UI elements in the view to properties in the view model. When the bound properties change in the view model, the corresponding UI elements in the view automatically update, and vice versa.

Mapping is often used in view models to transform and adapt data between different representations. During a method that specifically require mapping, the entities are retrieved from the data source, mapped to view models using AutoMapper, and further processed or filtered as needed. Finally, the view models are assigned as the data source for the view, allowing them to be bound to UI controls and displayed to the user. Since I’m using AutoMapper, I also needed define mapping profiles that specify how properties from a source object should be mapped to properties in a destination object. These profiles can be configured with mapping rules, such as explicitly defining how specific properties should be mapped or specifying custom transformations using lambda expressions.

Lastly, events play a crucial role in MVVM for handling user interactions and notifying the view model of various actions or state changes. Events can be raised in the view when certain user actions occur, such as button clicks or selection changes, and the view model subscribes to these events to perform the appropriate actions or update its internal state accordingly.

Overall, by understanding these concepts and their application in the example view model had assist me in implementing the requested features, that is adding a filter with search functionality and pagination to the entity list in the sand box user interface.

Last week, I embarked on a task to learn and discover the wonders of WPF (Windows Presentation Foundation), MVVM (Model-View-ViewModel), and Prism. I was thrilled to dive into these concepts, eager to expand my knowledge and enhance my skills. My first instinct was to turn to YouTube, so that I can grab a quick viewpoint of the concept before diving into the details.

I stumbled upon a video that aimed to teach XAML, the declarative markup language used in WPF. The video also touched upon the usage of code-behind, which involves writing code directly in the code-behind file of a XAML-based application. However, Mr. Peter advised focusing on MVVM rather than code-behind because the system we are now utilizing relies heavily on MVVM rather than code-behind. One of the significant reasons why MVVM was used instead was because by utilizing MVVM, we can effectively test the code. On the other hand, if we rely heavily on code-behind, it becomes challenging to isolate and test the code in a systematic manner. Code-behind tightly couples the user interface (View) and the underlying logic, making it difficult to isolate and verify specific functionalities independently. This lack of separation of concerns impedes the ability to write targeted unit tests, as the code-behind files often contain UI-related code that is tightly coupled with the View. 

MVVM stands for Model-View-ViewModel, and it provides a clear separation of concerns, making the codebase more maintainable, testable, and scalable. It promotes a clean architecture that isolates the business logic (ViewModel) from the user interface (View), with the Model representing the data and functionality. By adhering to MVVM principles, we can achieve a modular and extensible codebase. The ViewModel acts as a bridge between the Model and the View, ensuring efficient communication and decoupling of components. This separation is what allows for easier unit testing, as we can test the ViewModel independently of the View. Therefore, adopting MVVM promotes testability by providing a clear separation between the UI and the business logic, facilitating the creation of robust and easily testable code.

Hence, I centred my attention to grasping the skill of properly using XAML and the MVVM pattern effectively. XAML, an XML-based markup language, empowers developers to define user interfaces in a declarative manner, enhancing productivity and fostering a better collaboration between designers and developers. As I delved deeper into XAML, I was fascinated by its versatility. It provided me with a powerful set of tools to create rich and interactive user interfaces, with its support for data binding, styling and much more. Data binding, for example, is what fascinated me the most. In the context of MVVM, data binding allows for automatic updating of UI elements when the underlying data changes, and vice versa. We also don’t need to manually update the UI or handle events to keep it in sync with the data. 

Data binding supports various modes, such as OneWay and TwoWay, providing flexibility in how data flows between the ViewModel and the View. OneWay binding updates the UI when the source property changes, while TwoWay binding allows changes in the UI to propagate back to the source property. By utilizing data binding, we can create dynamic and responsive user interfaces without writing extensive code for manual updates. It simplifies the development process, enhances code maintainability, and promotes a separation of concerns between the UI and the underlying data logic.

While exploring Prism, a framework for building composite applications in WPF and other XAML-based platforms, I was introduced to its modularity and navigation capabilities. Prism embraces the MVVM pattern and offers a range of features that streamline application development, including dependency injection, event aggregation, and region management. It enables the creation of scalable and maintainable applications with ease. 

Throughout this journey, I realised that grasping the fundamental ideas and patterns is like exploring a vast realm of potential. It is not enough to know how to create code or utilise certain tools, it is also necessary to understand the basic principles that form these technologies.