Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Code Block
...
public HarvestStatusQuery(ServletRequest req) {
  String[] statuses = (String[]) UI_FIELD.JOB_STATUS.getValues(req);
    for (String s : statuses) {
      if (JOBSTATUS_ALL.equals(s)) {
        this.jobStatuses.clear();
        break;
      }
    this.jobStatuses.add(JobStatus.parse(s));
  }
...

First of all, the data - server layer decoupling is broken because this data layer specific method contains a server layer type argument argument. This means the data layer has knowledge of the server implmentation , eg. (it is a web service).

But even worse is that the GUI logic is exposed in this code. Both by the type of data used (f.ex. UI_FIELD), but also in the methods from these classes which contains functionality specific for the gui. In case of the UI_FIELD.JOB_STATUS.getValues(ServletRequest)

...

The reason for the added problem with exposing gui related functionality, is that it very difficult to validate gui codewith code with automatic testing.This is one of the reasons motivations for the many GUI centric design patterns like the MVC pattern, which is an attempt are attempts to isolate the presentation layer specific code even further compare to a simple 3-tier architecture.

And An example of the dangers of working with such closely couple code would be the change changing of the HarvestStatusQuery constructor to better reflect only data layer concerns. This will certainly break the application in some way, but the precise implications are difficult to isolated and the automatic regression test will not be very helpful, because is properly doesn't affect the GUI code.