иерархия услуг Grails - PullRequest
       0

иерархия услуг Grails

2 голосов
/ 29 октября 2011

Допустим, у меня есть 10 услуг Grails.Каждая из этих служб будет звонить в службу REST.Итак, я хотел бы инкапсулировать код REST, чтобы его можно было легко повторно использовать 10 службами.

При рассмотрении вариантов я мог бы:

1) создать другой сервис или компонент с помощью RESTсвязать код и внедрить его в каждую из 10 служб.
2) создать службу суперкласса, содержащую код REST, и сделать так, чтобы все 10 служб grails расширяли этот класс.

Я пытаюсь использовать вариант 2, но сталкиваюсь с проблемами с внедрением зависимостей в суперкласс.

Пример:

class SuperService {
   def aString 
}

class ExampleService extends SuperService {
}

resources.groovy:

beans = {
    superService(SuperService) {
        aString = "something"
    }
    exampleService(ExampleService) {
    }
}

Когда я запускаю это в отладчике во времяЗапустив интеграционный тест, я вижу, что значение aString равно нулю.Очевидно, это будет проблематично для меня.

Как и следовало ожидать, запустить тот же код со следующими ресурсами.groovy:

beans = {
    superService(SuperService) {
    }
    exampleService(ExampleService) {
        aString = "something"
    }
}

и aString = "кое-что".

Итак, я предпочитаю вариант 2, потому что это будет меньше конфигурации проводки, но я не думаю, что это будет осуществимым подходом.Другими словами, нет никакого смысла, если мне нужно установить aString в каждом из подклассов.

Мысли?

Я что-то упустил?

Я открыт дляа также другие варианты.

Заранее спасибо, Тодд

1 Ответ

0 голосов
/ 31 октября 2011

У вас есть правильная идея с опцией № 2 с точки зрения того, что она СУХАЯ - но на самом деле это всего лишь одна строка.Если единственной общей чертой объекта superService является сервис, а не другие методы, то вы действительно не экономите на работе.Во всяком случае, просто объявление суперкласса для внедрения зависимостей делает вещи более скрытыми и, возможно, труднее поддерживать.

Это звучало так, как будто вы предлагаете поместить методы REST в superService, поэтому не знаете, почему вас беспокоит внедрение зависимостей в superService - вам нужно, чтобы ваши методы выполняли взаимодействия REST, которые и подкласс делаютсможет позвонить.Или вы пытаетесь комбинировать варианты 1 и 2?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...