Hi Curt, Interesting you mention Prevayler. In the dim and distant past (about 2004) I remember that Rob Matthews - the framework's original author - did a spike on using Prevayler as a persistence approach, for much the same reasons that you suggest. This was prior to the framework being integrated with DataNucleus, though (we used to have an pluggable SPI but it has since been removed).
That said, I can think of several options to remove boilerplate: 1. (as discussed at IsisCon2017), the chances are that many of the JDO annotations that we habitually put into our entities could be removed; we've just never really spent the time deciding if the DN defaults are appropriate, nor leveraged any of DN's various extension points to remove the boilerplate. For example, specifying @Column probably isn't needed in many cases for a string if you are happy with a default of varchar(255), for example 2. a lot of the boilerplate is because of using JDOQL to specify queries on the entities. Moreover, these JDOQL definitions are a long way distant from the repositories that use them. So a better approach might be to use type safe queries. These have some limitations in DN 4.1 (the version we are currently on), but get several improvements in DN 5.1, scheduled for Isis 1.16.0. 3. another alternative that is available as of DN 5.1 is its support for custom meta-annotations. Thus one could define @EmailAddress for example as a meta-annotation and apply the @Column annotation etc to it. We also intend to support this in a future version of Isis also (perhaps 1.16.0) which would help unify the semantics. 4. another option to remove DN annoations is to use XML. You can download the corresponding XML metadata using the contributed mixin for each entity. A completely different route is to build your application without using entities, and just using view models. We have had several implementations of view models over the years, right now my recommendation is to stick with JAXB view models [1] because they are the most flexible. However, doing so adds a different set of boilerplate. This is where Prevayler could be slotted in. I think it would be comparatively easy to implement the FacetFactory and Facets that use Prevalyer to serialize the state of a domain object, instead of JAXB: the appropriate facet to look for is RecreatableFacet. The UrlEncodingService [2] could then be used to act as a key into the Prevayler store. A couple of downsides I can see in using view models, though: - you would have to figure out an appropriate way to manage queries. Perhaps combining with ElasticSearch might mitigate this issue, though? - how would the system distinguish persistent entities from transient view models? - or perhaps one doesn't care? Hope that helps; I've raised ISIS-1645 [3] to capture the above thoughts. Do let me know if you decide to look into this further. Cheers Dan [1] http://isis.apache.org/guides/ugfun/ugfun.html#_ugfun_programming-model_view-models_jaxb [2] http://isis.apache.org/guides/rgsvc/rgsvc.html#_rgsvc_presentation-layer-spi_UrlEncodingService [3] https://issues.apache.org/jira/browse/ISIS-1645 On Wed, 5 Jul 2017 at 16:21 Curt Cox <[email protected]> wrote: > Has anyone tried using Isis with Prevayler[1] or airomem[2]? > > Much of the boilerplate of Isis appears to be due to persistence. Perhaps > the above frameworks would be a good way to eliminate this boilerplate for > a large class of applications. > > If you have experience, thoughts, or advice on this combination I would > love to hear more. > > Potential starting points would be especially welcome. > > - Curt > > [1] http://prevayler.org/ > [2] https://github.com/airomem/airomem >
