Let's see if we can use the knowledge acquired in this book and use it to design a new application.
When doing this, we can apply Patterns and coding concepts in a new module that users will recognize to be a Microsoft Dynamics NAV application, and which is easy for other developers to understand and maintain.
The solution that we will make is for a small bed and breakfast (B & B), allowing them to manage their rooms and reservations. This can be integrated into the financial part of Dynamics NAV.
It is not the intention of this chapter to make a full-featured finished product. We will discuss basic design principles and decision-making processes. Therefore, we will simplify the functional process. One of the restrictions in our application is that we rent rooms per night.
This chapter will be covering the following topics:
- Building blocks
- Creating the Table objects
- Applying the Design Pattern
- Defining the methods
- Writing code and linking methods
- Refactoring
- Testing the application
- Upgrading our application
- Building our application
- Managing our source code
We borrowed the term classes from object-oriented programming as a collection of things that belong together. Classes can be Tables or Codeunits in Microsoft Dynamics NAV.
The first step in our process is to define the classes. These will be created as Tables or Codeunits, following the Patterns that we have learned:
|
Setup |
This is a generic set of parameters for the application |
|
Guest |
This is a person who stays at our B & B. This can be one person, two persons, or a group (family) |
|
Room |
Our B & B has a number of rooms with different attributes that determine the price, together with the season |
|
Season |
This is the time of the year |
|
Price |
This is the price for one night in a room |
|
Reservation |
Rooms can be reserved on a day-by-day basis with a start and end date |
|
Stay |
This is a set of one or more consecutive nights at our B & B |
|
Check-In |
This is the start of a Stay; checking in for reservation |
|
Check-Out |
At the end of a Stay, we would like to send a bill |
|
Clean |
Whenever a room is cleaned, we would like to register this |
|
Evaluation |
Each Stay can be evaluated by a Customer |
|
Invoice |
This generates a Sales Invoice for a Stay |
The second step is to decide per class the Architectural Patterns that we can use. We will use the Patterns that we learned in Chapter 2, Architectural Patterns, but in some special cases we might need to write down some new Patterns, based on the data structures that are not used in the standard application, or the Patterns that are outside the scope of this book.
For the application setup, we will use the Singleton Pattern. This allows us to define a single set of values for the entire application that is kept in memory during the lifetime of the system.
To register our guests, we will use the standard Customer table in Dynamics NAV. This has pros and cons.
The good thing about doing this is the ability to use all the standard analysis options in the application for our customers without reinventing the wheel. Some B & B users might decide to also sell souvenirs or local products, so they can use items and the standard trade part of Dynamics NAV. We can also use campaigns in the Relationship Management module.
The bad part, or the challenge, is upgradability. If we were to add fields to the customer table or modify the standard page elements, we would have to merge these into the application each time we got a new version of the product, which is once a month. We will use the new Delta file to challenge this ,as well as the testability framework.
The Architectural Pattern for a room is a tough decision to make. Most users of our system run a small B & B, so we can consider rooms to be as setup data. Number Series is not a required Pattern. We will therefore decide to implement a Supplemental Table.
Each B & B can setup their own seasons. They are used to determine price, but when not used, the system will have to work too. We will implement a Supplemental Table too.
Rooms can have a default price, or a price per season and guest. Based on this requirement, we will implement the Rules Pattern, which allows us a complex array of setup values.
We want to carefully trace the reservations and cancellations per room and per guest. We would like to analyze the data, based on a season. For this feature, we will implement the Journal Template-Batch-Line Pattern, and introduce an Entry table that is managed by the Journal.
We would like to register each unique stay in our system rather than individual nights. This allows us to easily combine parameters and generate a total price. We will implement this as Master Data, based on the requirement to be able to use Number Series. The Stay does not have requirements for a lines table, nor does it represent a document in our organization.
When a guest checks in to the bed and breakfast, we can check a reservation and apply the reservation to the Stay.
When a guest leaves, we would like to set up the final bill, and ask to evaluate the stay. This process will be a method on the Stay class with encapsulated functions, creating the sales invoice and generating an evaluation document.
Rooms have to be cleaned each day when a guest stays, and at least once a week when the room is empty.
We will use the Entry Pattern without a journal. Clean will be a method on the Room class. Each day, we will generate entries using the Job Queue Entry Pattern. The Room will also have a method that indicates if it has been cleaned.