Сервисно-ориентированный подход без сохранения состояния и богатые модели с сохранением состояния - PullRequest
Новая
       31

Сервисно-ориентированный подход без сохранения состояния и богатые модели с сохранением состояния

1 голос
/ 20 февраля 2012

Скажите, что у меня определен набор предметов. Эти предметы должны быть сгруппированы в разные наборы. Например, элементы могут быть как 

public Item {
    public int id;
    public String name;
}

и наборы имеют свои собственные настройки, например, какие элементы принадлежат этому набору, каково имя набора и т. Д. Теперь все эти вещи хранятся, скажем, в структуре XML.

Моей первой идеей было бы написать следующие элементы:

  • xml-анализатор для получения данных набора и преобразования в MySet pojo

  • xml-анализатор, чтобы получить все предметы и преобразовать их в список предметов pojos

  • сервис-подобный класс без состояния, скажем, ItemsSetCreator, вычисляющий конечный объект ItemsSet, содержащий определение набора на основе MySet и список элементов, таких как 

    class ItemsSetCreator {

     public ItemsSet createItemsSet(List<Item> items, MySet set) {
         // ...
     }
}

Но другим подходом было бы немного обогатить модель и написать что-то вроде:

  • Класс MySet, способный получать все элементы, применять к ним внутреннюю логику на основе xml-данных и предоставлять в результате итоговый ItemSet

  • и т.д.

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

1 Ответ

1 голос
/ 20 февраля 2012

Все зависит от вашего варианта использования и степени детализации, поэтому сложно ответить на ваш вопрос окончательно. Обогащение моделей может быть полезным, но вы не хотите спускаться по этому скользкому склону.

Если бы у меня было , чтобы выбирать между высокосвязанными "богатыми" моделями спагетти-кода и скучными анемичными моделями, я бы выбрал анемичные модели. Но использование reductio ad absurdum здесь ничего не решает, поэтому мы возвращаемся к моей исходной точке: это зависит от вашего варианта использования. Иногда вы хотите / должны иметь модели поведения. Иногда нет. Большую часть времени вы находитесь где-то посередине.

Ваша работа как разработчика и архитектора состоит в том, чтобы выяснить, сколько моделей поведения действительно нужно.

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

...