3

I'll admit I'm a spring newbie, but you can correct me if I'm wrong, this one liner looks kinda fishy in a best practices sort of way:

@RepositoryRestResource(collectionResourceRel="people"...)
public interface PersonRepository
extends PagingAndSortingRepository<Person, Long>

For those who are unaware, the following does many things: It is an interface definition that can be registered in an application context as a jpa repository, automagically hooking up all the default CRUD operations within a persistence context (that is externally configured). and also configures default controller/request-mapping/handler functionality at the namespace "/people" relative to your configured dispatcher servlet-mapping.

Here's my point. I just crossed 3 conceptual layers with one line of code! this feels against my seperation-of-concern instincts but i wanted to hear your opinion. And for the sake of being on a question and answer site, I would like to know whether there is a better way of seperating these different layers - Service, Data, Controllers - whilst maintaining as minimal configuration as possible

1
  • For what its worth, I think this question is also relevant on SO because its a programming best practices kind of question.
    – JamesENL
    Jun 10 '14 at 3:29
1

Disclaimer: I do not know about that annotation so I will rest my answer in your definition.

When programming, we use layers because otherwise, when programming we risk running in a set of known problems. But if that line of code is all what you need to build all the functionality relative to a business object, you will not be programming it anymore, so you do not need to divide the code in layers (because there is no code to be divided).

If it does it all by itself, I would think of it more as Spring providing a "component" that is external to your application.

As an example, if you were using an LDAP client to manage your users and permissions, you would not worry that by using that client you are "crossing" conceptual layers. That is an issue "internal" to the LDAP client/server, and you just use the abstraction of the LDAP service.

Of course, before using it, you must decide if these business objects should be accessed directly. I also investigate how this "component" can interact with the rest of the application. At first glance, I can think of these issues:

  • Do you trust Spring to properly implement the component?

  • Does it support some kind of integration schema (maybe an observer model, so your business logic can know when an object is modified through the component)?

  • What would be the steps to take if you want to add, say, a Web UI that access the same data? Would you be able to hook up to the "CRUD methods", or would you have to replicate the functionality?

1

I've never used that annotation myself, and I suspect its for entirely the reason you've described. Yes you have a totally valid concern there. At a minimal level, just use @Repository, @Service, @Controller with <context:component-scan base-package="your.base.package" />. You can use generics at a DAO level if you want to create generic CRUD operations.

That annotation (I suspect), seems like it was designed to be used in Spring Security when trying to authenticate users using a REST call.

However I wouldn't be using that particular annotation in my application at all for exactly the reason you describe.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.