In the first post of this series I generally wrote about Prism and how can it fit in WPF applications. In this second post I would like to introduce a Home Automation application UI, show how to design it as a monolithic application, talk about the disadvantages of a monolithic application, and finally show how to design it as a Composite Application.
What is a Home Automation?
"For some it may be something as simple as remote or automatic control of a few lights. For others, security may be the central application. Still others may choose to install advanced controllers or use voice recognition. As a very basic definition, we tend to refer to home automation as anything that gives you remote or automatic control of things around the home." [http://www.smarthome.com/HomeAutomation.html]
Most of Home Automation solutions come with additional support to control lights, cameras, security and other endpoints using a simple computer. The User Experience provided by Home Automation applications is the key feature of these type of applications. The better the UX is, customers would like to buy your solution. UX can be measured by richness, simplicity, usability, etc. With the correct UI architecture, design and WPF you can develop a great UX.
Home Automation Application
Lets take a look on a list of requirements in a Home Automation Application.
- Control lights, boiler and other endpoint from UI, Web, Voice Recognition, Telephony, SMS and future options
- Receive events, notifications and query information of lights, temperature and other endpoints
- Schedule operations such as turn on lights, radio and shutters
- 2D/3D view and design of the deployment site (rooms, salon, etc)
- Controller and Endpoints configuration and programming
- More...
I believe that you can think about more and more and even more features. This is the reason for having this list of requirements opened for future features, and even the big reason to design your application to support Extensibility.
Monolithic Application
As a monolithic application solution, you would start with a top-level window and add user controls for each of the different requirements. In this case, you'd have user controls such as AutomationControl, AutomationEvents, AutomationStatus, Scheduler, SiteMap and other. Each user control has its own logic, and is laid out at design time within the main window or other windows, either manually in XAML or using a designer such as Expression Blend. You would then use RoutedEvents, RoutedCommands, and data binding to wire everything up. The window handles commands, events and acts as a mediator between each of the controls described so far. Using this approach, the application is tightly coupled to each of the controls. There is a significant amount of logic in the UI for coordinating the different pieces. There are also interdependencies among the controls.
Due to a tight coupling between controls and the window, there is no easy option to break down the application into pieces, where each piece can be developed and tested separately, by individuals or teams. With this approach, it is difficult to make significant changes or extend the solution with new functionality.
It can be further complicated by supporting features such as customizable views, where each customer can choose what he/she want to see in the main view, or by supporting multiple versions and deployment of the application, for example Standard, Professional and Enterprise.
Composite Application
In a composite application, things are look a little bit different. It is more about how you breakdown the solution into small parts called modules, where each module is an autonomous, discoverable and dynamic loaded piece, contains its own view, logic and services and is independent and unaware of other modules. Each shell (window) in the Composite Application contains one or more placeholders in a layout, for hosting dynamic modules views.
Using this approach, it is easy to
- Develop and test each part of the application separately, by individuals or teams in parallel
- Create new modules with new functionality and dynamically load them into the application, with minor changes to the shell, if any
- Customize views and features based on configuration and user settings
- Create multiple versions of deployment such as Standard, Professional and Enterprise
You can think of a module as an Add-in but with no complication such as versioning, isolation, and security, developed by you, your team or other teams in your company.
Now as a Composite Application you would start by creating the main shell, with one or more placeholders in a layout for dynamic load views. Then you will continue by creating one or more modules, for example: AutomationControl, AutomationEvents, AutomationStatus, Scheduler and SiteMap modules. Each module may contain views, logic and services. Each one of these modules may load at runtime based on configuration, user settings or any other logic. New modules are free to be added to support future features.
In the next parts of this series, I will discuss about the technical stuff of Prism and show how to build a Home Automation Application using CAL (composite application library).