Должен ли мой уровень обслуживания быть без сохранения состояния? - PullRequest
Новая
       38

Должен ли мой уровень обслуживания быть без сохранения состояния?

2 голосов
/ 22 ноября 2011

У меня есть сервисный уровень, который связывает, например, мой контроллер с моделью моего домена (то есть: хранилище, сущности и т. Д.).

В моем сервисе у меня есть метод, который "получить "сущности, например getArticles, но мне нужно вернуть либо результат массива, либо коллекцию объектов.

Поэтому я добавил аргумент в свой метод getArticles($array = false); (На самом деле мой сервис не приводит ни к какому объекту, это делает репозиторий, но мне нужно предоставить эту опцию моему API)

Мой сервис становится все больше и больше, и мне интересно, если это хорошая идея, чтобы определить его в параметре моего метода, яЯ подумал, что это потому, что я думал, что мой сервис должен быть без сохранения состояния, но мне интересно, не лучше ли иметь в своем сервисе метод, который в основном делает setUseArray($flag) и снабжает мой репозиторий этим флагом, когда мой сервис проксируетit.

По той же идее, если я использую свой сервис для возврата постраничного результата, я должен установить страницу и количество элементов в каждом из моих методов, или я должен использовать глобальный метод в моемсервис для этого?

Есть ли какие-либо отзывы?

1 Ответ

1 голос
/ 23 ноября 2011

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

class request { 
    bool getArrayInsteadOfCollection;
    int pageNumber;
    int itemsPerPage;
}

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

getArticles(filterParam) {
    //combine function and service-object-level parameters.
    repository.load(fitler = filterParam, itemsPerPage = this.itemsPerPage...)
}

На мой взгляд, проходить через параметры предпочтительнее из-за гибкости и минимизации побочных эффектов.

...