Что это за шаблон проектирования - адаптер, поставщик, делегат, методы шаблона или ...? - PullRequest
1 голос
/ 13 октября 2011

Вот простой вопрос о шаблонах проектирования:

В рамках моего текущего проекта я написал интерфейс, который выполняет поиск в базе данных (используя веб-сервисы и соответствующие клиентские заглушки) и возвращает результаты - которые впоследствии будут использоваться действием Struts в качестве ответа на запрос JSON.

Интерфейс примерно такой:

    public interface DynamicSearchProvider {

        JSONObject getSearchResultsAsJSONObject(DatatablesRequestParams params) 
                throws JSONException;

    }

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

На самом деле, насколько я могу судить, это всего лишь оболочка бизнес-логики.

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

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

EDIT:

Вот где он используется:

public abstract class GenericDynamicSearchAction extends GenericAction {

    private static Log log = LogFactory.getLog(GenericDynamicSearchAction.class);

    /**
     * Method to be implemented by each individual search action
     */
    public abstract DynamicSearchProvider getDynamicSearchProvider();

    public final ActionForward executeAuthenticated(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws IOException {

        log.debug("called");

        DatatablesRequestParams datatablesRequestParams = DatatablesUtils.extractDatatablesParamsFromRequest(request);

        try {


            JSONObject jsonResponse = getDynamicSearchProvider().getSearchResultsAsJSONObject(datatablesRequestParams);

            String echo = datatablesRequestParams.getEcho();

            jsonResponse.put(DatatablesUtils.ECHO_FIELD_NAME, echo);
            response.setContentType("application/json");

            String jsonResponseString = jsonResponse.toString();

            log.debug("Returning JSON response:"+jsonResponseString);

            response.getWriter().print(jsonResponseString);

        } catch (JSONException e) {

            response.setContentType("text/html");
            response.getWriter().print(e.getMessage());

        }

        return null;

    }

и т.д ...

Таким образом, для конкретного типа объекта реализована конкретная версия вышеупомянутого класса Action (кстати, это действие stuts), и у него будет ссылка на реализацию вышеуказанного «Provider» ... как это:

public class PolicyDynamicSearchAction extends GenericDynamicSearchAction {

    @Override
    public final DynamicSearchProvider getDynamicSearchProvider() {

        return new PolicyDynamicSearchProvider();

    }
}

и

public class PolicyDynamicSearchProvider implements DynamicSearchProvider {

    public final JSONObject getSearchResultsAsJSONObject(DatatablesRequestParams params) throws JSONException {
//some business logic that goes to webservice etc to get the info
}
}

Надеюсь, это прояснит ситуацию.

Ответы [ 2 ]

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

Догадываясь от вас "куча бизнес-логики", это Фасад. Тем не менее, ИМХО именование классов после шаблона проектирования вообще не очень хорошая идея. Во-первых, класс может реализовать несколько шаблонов проектирования одновременно, во-вторых, этот подход трудно поддерживать во время рефакторинга.

Я думаю, что это особенно неправильная идея с фасадом, так как он не должен знать о том, что метод работает как фасад.

Провайдер звучит хорошо, но DynamicSearchService звучит лучше для меня.

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

Это не моя область знаний, но я думаю, что это звучит как шаблон стратегии

...