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
<[email protected]> 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 <[email protected]>
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 <[email protected]>
> 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
> >
>
