Facade class and rule management

bgilbert posted on Monday, September 10, 2007

In my app, I have a class called EmployeeEvent that is responsible for tracking an employee's activities on the shopfloor. An event represents an employee moving from one activity to another. The UI needs to maintain a relationship between the employee's previous event and the new one being created, all within a transaction. To facilitate this, we're using a facade class to manage the two events and to expose filtered lists for a couple of UI dropdowns.

One of the debates is where to maintain the rules for the employee events, in the EmployeeEvent class or in the facade class. Many of these rules deal with relational constraints. For example, we do not allow events during a shift that has been closed and we do not allow an event's time to be closed if there is uncompleted work during that event's time frame. The two approaches we've discussed are:

A) Maintain all the rules in the facade class. The theory here is that the EmployeeEvent class should not be responsible for maintaining rules that require interaction with other classes. My concern with this approach is that, if the EmployeeEvent class were scoped public, it would expose unprotected properties.

B) Maintain rules in the EmployeeEvent class and use the facade class' filtered lists to prevent rules from ever being broken. In this case, the EmployeeEvent class interacts with whatever classes necessary to protected its own data and the facade class is merely used to help the UI. The question here, though, is how to deal with the possibility of broken rules in the EmployeeEvent class and bubble them up to the UI.

Any thoughts would be appreciated.

bgilbert replied on Tuesday, September 11, 2007

Correct. EmployeeEvent is not a child of Employee.

bgilbert replied on Wednesday, September 12, 2007

Dean,
There are three use cases:

1) User submits a single transaction that closes a previous employeeEvent, if it exists, and creates a new one. This requires coordination and event handling to manage the relationship between the two employeeEvents.

2) Supervisor initializes a shift, creating initial employeeEvents for each employee assigned to the shift.

3) Supervisor maintains previously recorded employeeEvents in a grid type UI.

The solution we've developed in the past two days involves using a switchable object for the employeeEvent class. This allows us to use it as a child when filling a collection for the grid-based UI. It also allows instantiation of two individual objects when we need to deal with the transaction of the previous and new employeeEvent. The employeeEvent class maintains the rules and the facade class is used by the first and second use cases to prevent the rules from being broken by managing the transaction.

This will work for now. I'm not convinced I have the perfect design, but it seems to be a reasonable division of responsibilities. We did, to your point, look at having the employee class manage employeeEvents, but we wanted to keep employees as more of a root object.

Thanks for your input.

Barry