Away-Day Planner App

We were tasked as a group of 5 to create an away-day planner for a hypothetical company that plans away-days for clients, given a brief of the functionality that is expected for an advanced programming C# Module in my final year of university.

I jointly led this project, identifying the key points in the brief to focus development on, as well as designing and implementing much of the core functionality of the program myself.

The project allows a user to register an account, login, and create a prospective away day using the pre-existing activities as well as creating their own. Once an away day is submitted, an admin account can view all pending away days, change the price of any activity to match a hypothetical quote (especially for custom activities, as these do not have a price initially), and confirm an away-day. Once reviewed, the user can then review their planned away days, review the price changes made by the admin, confirm their order and receive an invoice.

Overall, this is somewhat of a mock project as there is obviously no real payments being sent, and the database is currently a local .mdf file. However, these are changes that can easily be implemented into a real system on top of our project, as the system follows the Model-View-Presenter (MVP) system architecture, making changes and replacement components very simple and easy to implement. Database access itself uses Microsoft's Entity Framework in a code-first approach, meaning that no direct use SQL is required as records are read from and written to the database as objects. This simplifies data storage significantly, and is something I greatly enjoyed using in this project.

Other design patterns we used focused heavily on abstraction and dependency injection, as well creational design patterns such as an abstract factory for efficiently creating and cloning activity objects, and singletons for accessing the different layers of each of the forms.

Unit testing was used extensively throughout this project to ensure consistent functionality throughout the development process, and was very useful for easily and repeatedly ensuring any changes did not negatively impact the functionality of other areas. Testing was done using the MSTest framework, with mock objects being easy to use with dependency injection due to the abstract, modular structure of the project.

Version control was used a lot throughout this project via GitHub, as this allowed each of us to independently work on a component on a branch before committing and merging everything into the main branch.