Hi Mathieu,
thank you for starting this interesting conversation.
I think it is fine to implement services in plain Java or in plain Groovy
methods and you have highlighted some of the advantages over their
implementation using the Groovy DSL.
However in my opinion the Groovy DSL (even in its current "basic" version,
implemented thru a few lines of code, that could be enhanced and extended)
has some advantages too and may be preferred by a different audience of
"users" that are more focused on business rules than on programming; data
preparation scripts are also a good fit for the DSL.
Just my two cents,
Jacopo
On Sun, Nov 11, 2018 at 8:02 PM Mathieu Lirzin <mathieu.lir...@nereide.fr>
wrote:
> Hello,
>
> While I think using Groovy for implementing services is a better choice
> than Java, I am not convinced by the rationale of using Groovy DSL
> features. Here are the various drawbacks I see:
>
> - The service DSL breaks the function/method local scoping goodness by
> introducing various global variables (parameters, delegator, ...)
>
> - There is no clear disctinction between services and helper methods
> (private/public)
>
> - When Unit testing a helper method defined in a DSL script, a
> cumbersome mechanism for accessing the groovy method is required
>
> - DSL implicit class context abstraction is leaky, for example it is
> hard to understand what is the proper way to define a variable
> outside of a method and how to refer to it from this method.
>
> def foo = "foo"
> def barService() {
> print foo // => ERROR: No such property: foo for class: ...
> }
>
> IMO DSL features introduce accidental complexity with very little
> benefits. Since plain Groovy classes doesn't suffer from the downsides
> I described above and preserve the Groovy goodness (map literals,
> optional typing, ...), I recommend transitioning from DSL scripts to
> classes.
>
> What do people think?
>
> Thanks.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
>
