On Tue, Jul 30, 2013 at 10:04 AM, Erin Noe-Payne
<[email protected]>wrote:

> On Tue, Jul 30, 2013 at 10: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.
> >
> >>>
> >>> 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.
> >>>
> Regarding the authorization annotations I would assume we can not
> worry about it. We can add the functionality to the interface /
> implementation and authorization rules can be added on later.
>

If you don't work them now, at least open a Jira issue to fix them.


>
> >>> Thanks,
> >>> Dan Gornstein
>

Reply via email to