On 9 December 2014 at 15:32, Alexandru Vladut <[email protected]> wrote:
> Hi, > > I am currently working on a personal project where I try to apply the > principles of DDD. I am reading Dan's book "Domain Driven Design using > Naked Objects", trying to adapt the examples to the Isis Framework. During > my work I found some problems that I need to be clarified: > Welcome to the mailing list, Alex. > 1. The Value-Object pattern seems not to work as in the documentation. It > says that you need only to annotate your class with @Value and to implement > the interface ValueSemanticsProvider. But it worked only if I annotated the > field with @javax.jdo.annotations.Persistent and the getter with > @org.apache.isis.applib.annotation.NotPersisted. I didn't find any example, > neither in the SimpleObject nor in ToDoApp. Did I do anything wrong or can > I find an example anywhere? > > No, you've not done anything wrong... right now we aren't supporting the @Value semantics. The primary reason for this is because of our use of JDO/DataNucleus; there is no equivalent general purpose mechanism (other than to persist values as serializable byte[] arrays, not exactly satisfactory). This is something that I'd like to look at again; not having @Value means violating DRY, eg using strings and then having to specify the same semantics the would-be value type is used as a property or a parameter. But right now pragmatism wins out! > 2. The aggregates seem not to work (from what I read, it is supported only > for NoSQL). I read also on the site that it istn't fully supported and its > use is currently discouraged. What does it mean? Is rather recommended to > use the Value Types or there is another alternative? > > Again, this arises from using JDO. Aggregates were necessary as a "hint" for our old home-grown objectstores, eg NoSQL and XML, to tell it to persist referenced objects in-line. Now we use JDO as our ORM, it means there's nothing else in the framework that requires this semantic. The closest alternative is to use JDO embedded objects [1]. Haven't used this myself, but I think Oscar has, and think it should work. > 3. I would like to know, also, if it is possible to completely eliminate > the JDO for storage. Firstly I want to use a fully in-memory storage, > without any database (does the DomainObjectContainer support anything like > that?) and afterwards something else. > > Right now the objectstore API is pluggable, so you can change to an in-memory implementation by changing the "isis.persistor" key in isis.properties file to "in-memory". HOWEVER, doing that will break (or at least disable) some aspects of the framework, most notably dirty object tracking (eg as used for auditing capability) and also maintenance of bidirectional relationships. Accordingly, we are almost certain to remove this pluggable API in the future (in Isis 2.0 next year), so that we can continue to slim down the Isis framework's responsibilities and focus on domain metamodels and their representation. We might re-introduce a pluggable API in the future, but only as a means to supporting other full-fledged persistence solutions (eg EclipseLink or Hibernate) that support lazy loading/dirty object tracking etc. So my recommendation for now is that you stick with use JDO, but configure it (in the JDBC URLs in persistor.properties) to use an in-memory database (eg HSQLDB as in the archetypes, or H2). HTH Dan > Thank you, > Alex > [1] http://www.datanucleus.org/products/datanucleus/jdo/orm/embedded.html
