On Tue, Jul 30, 2013 at 9:15 AM, Erin Noe-Payne <[email protected]>wrote:
> On Tue, Jul 30, 2013 at 10:07 AM, Gornstein, Daniel S. > <[email protected]> wrote: > > > > > > -----Original Message----- > > From: Erin Noe-Payne [mailto:[email protected]] > > Sent: Tuesday, July 30, 2013 9:57 AM > > To: [email protected] > > Subject: Re: Service Layer Questions > > > > On Tue, Jul 30, 2013 at 6:50 AM, Gornstein, Daniel S. > > <[email protected]> wrote: > >> All, > >> > >> I am currently working on RAVE-1010 ( > https://issues.apache.org/jira/browse/RAVE-1010) updating the service > layers to support crud operations from the rest API. > >> > >> I was planning to add getAll, getCountAll, and getLimitedList to the > services with respective repositories who also implement those methods. > >> > >> Right now some of the services (WidgetService) return SearchResult > objects, while others (CategoryService) return List<Category>. > >> > >> Should I be switching all services to return SearchResult objects? > > > > The rest api will probably want SearchResults objects, to fill in the > > metadata. Possibly refactor to rename the any conflicting methods that > > do not return a SearchResults instance? > > > > So does this mean if there are already getAll methods for services which > return a list, keep them but with a different name and make a separate > getAll which returns a SearchResult? > > > That is what I'm suggesting for minimum impact. If the current getAll > methods are not used widely you could just change the method signature > to return a SearchResults and then propagate that through. I don't > really have a strong opinion. > They definitely should all be returning the same object. Search Results is fine so long as it encompasses the functionality we want to have for return results. > > >> > >> Also I noticed on some of the methods in interfaces for the services > have spring annotations of @PostAuthorize or @PostFilter. > >> > >> I was wondering what the appropriate use cases are as they are not on > every service interface, nor on every method in the interface. > >> > >> Thanks, > >> Dan Gornstein >
