Introduction
Each complete module has:
a Window Handling Object WHO: specifies the behavior of the controls
a BusinessObject busObj: data manipulation; direct access to the dataSet (and dataSet fields)
at least one DataSet
A Window Handling Object defines the behavior of the window itself and of the controls within it. It is the place where the âcall-to-actionâ happens, i.e. it can respond to event handlers of any type. It responds to various events triggered by the window or by the controls, it holds references to the controls and can modify their properties at any given time. It does not contain business logic functionality; it delegates the functionality to the Business Object. It is the component that is able to handle exceptions and decide how the exception is handled (show message to user, retry, fail silently, etc.)
A Business Object is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database. It is an executor of commands usually triggered by a Window Handling Object or a parent Business Object.
It should not implement events of any type; the responsibility of âcall-to-actionâ belongs to the Window Handling Object.
It does not reference any visual components (WPF); it does not display user-level information.
When an unexpected result occurs inside of a function, the best practice would be to throw Exception instead of returning error-value.
It should not handle Exceptions in try/catch blocks; in the catch blocks, it should always call âthrow;â after some action is performed such as Logging the error.
Uses LoggerSink sparingly (best practice: not at all).
Last updated