Apache Isis vs Grails

[Stephen Cameron <st...@gmail.com>]

Hi,

Anyone care to share their thoughts on this comparison: Apache Isis vs
Grails? Relative strengths and weaknesses.

Maybe some main things to look at myself, I am committed to Isis for the
current project, but should know more about Grails I now see.

Thanks
Steve Cameron

Re: Apache Isis vs Grails

[David Tildesley <da...@yahoo.co.nz>]

Hi Stephen,
It is not valid to compare Grails generation of "scaffolding" from database tables to the ISIS UI generation from rich problem domain layer objects. 
Grails "scaffolding"  is just a CRUD generation with totally anemic domain objects and then from there it is all custom coding on all layers. Just like Spring Roo and JBoss SEAM and other such CRUD generating frameworks.
ISIS on the other hand is UI generation all the way (full lifecycle) from the rich domain layer objects you write and annotate.  That's why ISIS produces highly maintainable applications with a much higher probability of problem domain fit. Read Martin Fowler on the "anemic domain model" anti-pattern and Eric Evans on "Domain Driven Design". As Dan says it allows the developers to concentrate on the problem domain layer where the true business value lays, without getting sidetracked. Of course developers can still screw it up - but it's much easier to pick up "daftness" in code reviews because there is way less code to review in an ISIS app.
If I were a CIO who understood these things, I know which I would telling my developers and architects to use.
If you must have a "hand" crafted UI for specialised purposes, apart from grafting in custom wicket widgets,  ISIS provides a generated RO interface to be called from another app (e.g mobile native app or RIA or similar). 
Cheers,David.

 


     On Saturday, 18 July 2015 7:51 AM, Stephen Cameron <st...@gmail.com> wrote:
   

 Hi Dan,

Thanks for detailed response, its much appreciated. What you have said
agrees with my understanding of Apache Isis so far, and which is both
reassuring and inspiring (particularly the long life-span bit).

I think Grails does have an auto-generated UI, or rather generates
templates from off the domain model, that you can then customise further.
But as you imply, this is only partially Naked Objects, so Grails is for
developer efficiency, not necessarily for user efficiency, maybe.

A simple side-by-side comparison table could be beneficial I think,
something to add to the todo list. But an idea that comes to me is to be
able to script an Isis app using possibly Groovy, I am thinking of a
dynamic query capability here, but also in regards to fixtures and
data-migration. As another add-on it could have a place. Beyond my
capabilities at present, but definitely in my sphere of interests.

Cheers

On Sat, Jul 18, 2015 at 12:32 AM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:

> It's a good question, Steve, and - having not used Grails - one I'd be
> grateful for insight into myself; something to go in our docs [1]
>
> FWIW, my own view is that Apache Isis sits at a higher level of abstraction
> than Grails (or pretty much every other web framework out there).  That
> brings with it the usual trade-offs; more productive while you are working
> within the framework's assumptions, but more effort when you need to step
> outside.  Isis does of course have various ways of being customised, and if
> you know Apache Wicket (or can hire someone who does) then it's quite easy
> to bend Isis' UI to different views; see for example [2] which is a bunch
> of custom pages alongside and on top of an Isis app.
>
> I believe that Grails uses an MVC pattern, with explicitly coded
> controllers and views (as well as the domain model).  That'll let you write
> pretty much anything you like in terms of a UI, but it'll also introduce a
> lot of unnecessary overhead if the UI you are after is similar to that
> which Apache Isis provides.  That overhead shouldn't be underestimated...
> it's the maintenance of all those extra layers of code that really impacts
> agility and the ability to iterate to deeper and richer domain models.
>
> The Isis addons are also a pretty significant differentiator: having
> off-the-shelf implementations for security + multi-tenancy,
> command/auditing, publishing, as well as more esoteric stuff such as docx
> mail merging, feature toggles and random data services, is a big win.    So
> too is the polymorphic navigation pattern that's in there, key to decoupled
> subdomain/modules.  This is a level of sophistication that I doubt most
> developers using Grails would get anywhere close to considering.
>
> Testing too is probably quite different... I imagine the only way to
> properly test a Grails app is to use Selenium, whereas with Apache Isis we
> have our integration testing tool and supporting wrapper factory.
>
> One consideration might be the length of time you intend to the application
> to live for.  We know that naked objects systems are good at maintaining
> their architectural integrity ... witness the NO system for the government
> in Ireland, that after over a decade still ships a new release each month.
> And Apache Isis as a framework is quite a long way more sophisticated and
> thought through than even that system.
>
> All that said, Grails is a very capable framework, and probably one of the
> better ones out there.  And it has a lot of users and an active community,
> all stuff that is important and shouldn't be overlooked.  If I'd never come
> across the naked objects pattern, I imagine I'd be writing systems in a
> framework such as Gails.
>
> Very interested in other opinions, but I hope that helps.
>
> Cheers
> Dan
>
> [1]
>
> http://isis.apache.org/guides/ug.html#_ug_core-concepts_principles_apache-isis-vs
> [2] https://my.tellmegen.com
>
> On 17 July 2015 at 03:14, Stephen Cameron <st...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Anyone care to share their thoughts on this comparison: Apache Isis vs
> > Grails? Relative strengths and weaknesses.
> >
> > Maybe some main things to look at myself, I am committed to Isis for the
> > current project, but should know more about Grails I now see.
> >
> > Thanks
> > Steve Cameron
> >
>


  

Re: Apache Isis vs Grails

[Stephen Cameron <st...@gmail.com>]

Hi Dan,

Thanks for detailed response, its much appreciated. What you have said
agrees with my understanding of Apache Isis so far, and which is both
reassuring and inspiring (particularly the long life-span bit).

I think Grails does have an auto-generated UI, or rather generates
templates from off the domain model, that you can then customise further.
But as you imply, this is only partially Naked Objects, so Grails is for
developer efficiency, not necessarily for user efficiency, maybe.

A simple side-by-side comparison table could be beneficial I think,
something to add to the todo list. But an idea that comes to me is to be
able to script an Isis app using possibly Groovy, I am thinking of a
dynamic query capability here, but also in regards to fixtures and
data-migration. As another add-on it could have a place. Beyond my
capabilities at present, but definitely in my sphere of interests.

Cheers

On Sat, Jul 18, 2015 at 12:32 AM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:

> It's a good question, Steve, and - having not used Grails - one I'd be
> grateful for insight into myself; something to go in our docs [1]
>
> FWIW, my own view is that Apache Isis sits at a higher level of abstraction
> than Grails (or pretty much every other web framework out there).  That
> brings with it the usual trade-offs; more productive while you are working
> within the framework's assumptions, but more effort when you need to step
> outside.  Isis does of course have various ways of being customised, and if
> you know Apache Wicket (or can hire someone who does) then it's quite easy
> to bend Isis' UI to different views; see for example [2] which is a bunch
> of custom pages alongside and on top of an Isis app.
>
> I believe that Grails uses an MVC pattern, with explicitly coded
> controllers and views (as well as the domain model).  That'll let you write
> pretty much anything you like in terms of a UI, but it'll also introduce a
> lot of unnecessary overhead if the UI you are after is similar to that
> which Apache Isis provides.  That overhead shouldn't be underestimated...
> it's the maintenance of all those extra layers of code that really impacts
> agility and the ability to iterate to deeper and richer domain models.
>
> The Isis addons are also a pretty significant differentiator: having
> off-the-shelf implementations for security + multi-tenancy,
> command/auditing, publishing, as well as more esoteric stuff such as docx
> mail merging, feature toggles and random data services, is a big win.    So
> too is the polymorphic navigation pattern that's in there, key to decoupled
> subdomain/modules.  This is a level of sophistication that I doubt most
> developers using Grails would get anywhere close to considering.
>
> Testing too is probably quite different... I imagine the only way to
> properly test a Grails app is to use Selenium, whereas with Apache Isis we
> have our integration testing tool and supporting wrapper factory.
>
> One consideration might be the length of time you intend to the application
> to live for.  We know that naked objects systems are good at maintaining
> their architectural integrity ... witness the NO system for the government
> in Ireland, that after over a decade still ships a new release each month.
> And Apache Isis as a framework is quite a long way more sophisticated and
> thought through than even that system.
>
> All that said, Grails is a very capable framework, and probably one of the
> better ones out there.  And it has a lot of users and an active community,
> all stuff that is important and shouldn't be overlooked.  If I'd never come
> across the naked objects pattern, I imagine I'd be writing systems in a
> framework such as Gails.
>
> Very interested in other opinions, but I hope that helps.
>
> Cheers
> Dan
>
> [1]
>
> http://isis.apache.org/guides/ug.html#_ug_core-concepts_principles_apache-isis-vs
> [2] https://my.tellmegen.com
>
> On 17 July 2015 at 03:14, Stephen Cameron <st...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Anyone care to share their thoughts on this comparison: Apache Isis vs
> > Grails? Relative strengths and weaknesses.
> >
> > Maybe some main things to look at myself, I am committed to Isis for the
> > current project, but should know more about Grails I now see.
> >
> > Thanks
> > Steve Cameron
> >
>

Re: Apache Isis vs Grails

[Dan Haywood <da...@haywood-associates.co.uk>]

It's a good question, Steve, and - having not used Grails - one I'd be
grateful for insight into myself; something to go in our docs [1]

FWIW, my own view is that Apache Isis sits at a higher level of abstraction
than Grails (or pretty much every other web framework out there).  That
brings with it the usual trade-offs; more productive while you are working
within the framework's assumptions, but more effort when you need to step
outside.  Isis does of course have various ways of being customised, and if
you know Apache Wicket (or can hire someone who does) then it's quite easy
to bend Isis' UI to different views; see for example [2] which is a bunch
of custom pages alongside and on top of an Isis app.

I believe that Grails uses an MVC pattern, with explicitly coded
controllers and views (as well as the domain model).  That'll let you write
pretty much anything you like in terms of a UI, but it'll also introduce a
lot of unnecessary overhead if the UI you are after is similar to that
which Apache Isis provides.  That overhead shouldn't be underestimated...
it's the maintenance of all those extra layers of code that really impacts
agility and the ability to iterate to deeper and richer domain models.

The Isis addons are also a pretty significant differentiator: having
off-the-shelf implementations for security + multi-tenancy,
command/auditing, publishing, as well as more esoteric stuff such as docx
mail merging, feature toggles and random data services, is a big win.    So
too is the polymorphic navigation pattern that's in there, key to decoupled
subdomain/modules.  This is a level of sophistication that I doubt most
developers using Grails would get anywhere close to considering.

Testing too is probably quite different... I imagine the only way to
properly test a Grails app is to use Selenium, whereas with Apache Isis we
have our integration testing tool and supporting wrapper factory.

One consideration might be the length of time you intend to the application
to live for.  We know that naked objects systems are good at maintaining
their architectural integrity ... witness the NO system for the government
in Ireland, that after over a decade still ships a new release each month.
And Apache Isis as a framework is quite a long way more sophisticated and
thought through than even that system.

All that said, Grails is a very capable framework, and probably one of the
better ones out there.  And it has a lot of users and an active community,
all stuff that is important and shouldn't be overlooked.  If I'd never come
across the naked objects pattern, I imagine I'd be writing systems in a
framework such as Gails.

Very interested in other opinions, but I hope that helps.

Cheers
Dan

[1]
http://isis.apache.org/guides/ug.html#_ug_core-concepts_principles_apache-isis-vs
[2] https://my.tellmegen.com

On 17 July 2015 at 03:14, Stephen Cameron <st...@gmail.com>
wrote:

> Hi,
>
> Anyone care to share their thoughts on this comparison: Apache Isis vs
> Grails? Relative strengths and weaknesses.
>
> Maybe some main things to look at myself, I am committed to Isis for the
> current project, but should know more about Grails I now see.
>
> Thanks
> Steve Cameron
>