Обратная зависимость между проблемами слоев

Question

Я строю систему управления для установки оборудования (система циркуляции воды). Я разработал его в двух слоях: слое описания аппаратного обеспечения и уровне управления.

+----------------------------------------------+ 
| Control (enables manipulation of devices) | 
+----------------------------------------------+ 
     | uses (decorates) 
     v 
+---------------------------------------+ (de)serialize +------------+ 
|   HW Description    |<--------------->| Files/DB | 
| (stores physical layout, cabling etc) |     +------------+ 
+---------------------------------------+ 

Слой описания оборудования содержит карту оборудования, описывающую, как трубы подключены к теплообменникам и другому оборудованию. Данные для этого уровня настраиваются для каждой установки и будут прочитаны во время выполнения. Поэтому все классы на уровне описания аппаратного обеспечения должны быть сериализованы так или иначе (через Hibernate/serialization to XML или так).

Контрольный слой будет украшать классы описания аппаратного описания интеллектом, поэтому теплообменник, например, получит связанный с ним HeatExchangerController.

В этой системе объекты в слое управления, возможно, придется искать их neirest соседей с помощью описания аппаратных средств, так что контроллер теплообмена может сделать что-то вроде

HeatExchangerController neighbour = this.getHeatExchanger().getInputPipe().getOtherSide().getHeatExchanger().getController(); 
neighbour.notify(highLoadAlert); 

Проблема в том, что это делает нижний уровень (аппаратный уровень), осведомленный об интеллекте над ним (его контроллер (ы)). Это не только нарушает одностороннее правило зависимости между уровнями, но поскольку все классы описания аппаратных средств должны быть сериализуемыми, это усложняет код, поскольку все ссылки на более высокие уровни должны быть необязательными, объявлены временными и т. Д.

Я немного застрял, пытаясь решить, хорошо ли это или плохой идеей сделать этот элемент управления доступным через слой описания HW, например, или если есть какие-то альтернативные подходы. Я могу только думать об одном методе, который включал бы зеркалирование и делегирование почти всего слоя описания HW, который кажется способным навязчивым быть хорошим.

Так что мой вопрос в том, что кто-либо из вас признает эту ситуацию и имеет какие-либо советы/опыты. У него есть имя? Существуют ли какие-либо хорошие шаблоны/передовые методы для этого, есть ли другие известные библиотеки/рамки, которые также были и работают вокруг этой ситуации?

спасибо.

Answer 1

Вы не показали нам, какую выгоду вы получите, отделив логику контроллера от описания оборудования. Вы уверены, что это разделение стоит усилий?

Похоже, вы строите Anemic Domain Model?

Answer 2

Возьмите подход, основанный на домене.

Если вы нарушаете систему по вертикали (домены). Тогда эти вертикальные компоненты могут разговаривать друг с другом через контроллеры и ничего больше. Сохраняйте горизонтальные слои в каждом домене, и слоирование является вертикальным в пределах домена, и каждый домен изолирован друг от друга, поскольку они могут общаться только через контроллеры.

Answer 3

не слишком уверен, в чем ваша проблема. если вы не хотите getController() метод в классе вашего оборудования, вы можете хранить Оборудование-> отображение контроллера в слабой хэш-карта

public class Controller 

    static WeakHashMap<Hardware,Controller> map = ... 

    static public Controller of(Hardware hw){ return map.get(hw); } 

    Controller(Hardware hw) 
    { 
     map.put(hw, this); 
    } 

---

очень часто, люди любят, чтобы добавить «удобные» методы , не имея страха сложности в зависимости

user.getThis() 
user.getThat() 
user.getTheOthers() 

в то время как User класс является основным классом, он не должен иметь Knowlege в этом, что и другие. Теперь код lt ot зависит от класса User, а класс User зависит от многих других классов. Конечным результатом является то, что каждый класс приложения зависит от каждого другого класса, большого шара беспорядка.

Answer 4

Это сложное решение, которое я имел в виду. Он добавляет украшение слой поверх слоя HW, который добавляет ссылки до уровня управления для каждого объекта HW:

                -+ 
+--------------------------+    +-----------------+ | 
| HeatExchangerController |    | PipeController |  > Controller Layer 
+--------------------------+    +-----------------+ | 
      ^1 controller      ^1 controller -+ 
      |          | 
      v 1 heatExchanger      v 1 pipe  -+ 
+---------------------------+ inputPipe 1 +------------------+ | 
| ControlAwareHeatExchanger |--------------| ControlAwarePipe | > Decorated HW Layer 
+---------------------------+ 1 otherSide +------------------+ | 
      |          |    -+ 
      v 1 realExchanger      v 1 realPipe -+ 
+---------------------------+ inputPipe 1 +------------+   | 
|  HeatExchanger  |--------------| Pipe  |   > HW Layer 
+---------------------------+ 1 otherSide +------------+   | 
                   -+ 

декорированный слой будет содержать код, как:

class ControlAwareHeatExchanger { 
    private final HeatExchanger realExchanger; 
    private final ControlAwarepipe inputPipe; 

    public ControlAwareHeatExchanger(HeatExchanger decoratee) { 
    realExchanger = decoratee; 
    inputPipe = new ControlAwarePipe(decoratee.getInputPipe()); 
    } 

    public ControlAwarePipe getInputPipe() { 
    return inputPipe; 
    } 

    ... 
}  

Таким образом, вы можете сделать:

ControlAwareHeatExchanger controlHE = heatExchangerController.getHeatExchanger(); 
ControlAwarePipe controlInputPipe = controlHE.getInputPipe(); 
ControlAwareHeatExchanger otherHE = controlInputPipe.getOtherSide(); 
HeatExchangerController otherController = otherHE.getController(); 

Таким образом, вы можете спуститься к украшенной Hw слоя, прыгать вокруг, а затем вернитесь к слою контроллера снова, все без Hw слоя знающего о слое управления.

Но, как вы можете видеть, вам нужно отразить все соединения и украсить весь слой HW, чтобы добиться этого. Будет задействовано много делегаций. Мысли?