2

Imagine that you have a Grails projects with a great service layer and you want to make sure that your team only accesses the model through your services.

Is it easily possible to restrict the dynamic finders so that they can be still used from within the service (same package) but not outside?

I can imagine to overwrite them, but then they are also gone for the service...

rdmueller
  • 10,742
  • 10
  • 69
  • 126
  • 1
    The easiest way is to communicate (train) it with your team, there are many ways they can access the models (direct sql). If you want it bulletproof an alternative approach is make those service accessible through apis and host them in separate application. – Alidad May 08 '14 at 06:34
  • @Alidad true. That's the easiest way. But I still hope to find a way to restrict the access of the finders to package level. It is true that there are workarounds, but they would be easy to detect – rdmueller May 08 '14 at 06:43
  • http://www.catalysts.cc/en/diskussion/grails-in-large-projects-part-2/ – Visme May 08 '14 at 07:54
  • @visme Yeah, I've seen that too! But it only states that there is no out of the box way. I am sure that a groovy master could come up with an ast transformation or something like that... – rdmueller May 08 '14 at 10:06

2 Answers2

1

There isn't really an easy way to restrict where method calls can from. You could write a global AST transformation which looks for dynamic finder calls and disallows all of them that do not come from a service. If you are versed in writing AST transformations that wouldn't be prohibitively complicated but it isn't trivial. If you are not versed in writing AST transformations then I do not recommend taking this on as your first adventure in that space. To be honest, I don't recommend it either way, but it is an answer to your question. It can be done, but I wouldn't say that there is an easy way.

Jeff Scott Brown
  • 26,804
  • 2
  • 30
  • 47
  • Yeah, I've now read a bit more about AST transformations - doesn't look like an easy way. I hoped that there would have been a way to change the missingMethod-Method from public scope to packagescope -- maybe through metaprogramming or maybe the same way the `@packagescope` transformation does it. But my hopes are vanishing :-| – rdmueller May 08 '14 at 18:02
  • Even if you could change missingMethod to package scope, that wouldn't accomplish what is being asked about. – Jeff Scott Brown May 08 '14 at 18:15
1

There is a grails plugin for CodeNarc, which does static analysis and can fail the build if a developer commits a violation.

There are several built-in Grails Rules, but they don't do what you want. You would need to create a custom rule. See this screencast.

The closest one is probably GrailsDomainWithServiceReference It checks that Grails Domain classes do not have Service classes injected.

Jay Prall
  • 5,295
  • 5
  • 49
  • 79