Thank you for your prompt answer.I will apply your hints :) 2014-12-09 19:22 GMT+02:00 GESCONSULTOR - Óscar Bou <[email protected]> :
> Hi, Alex. > > > 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. > > > > > We're not using embedded objects, but instead 1-1 relationships, that > works really good. > > If they're persisted or not in a different table is not a matter of DDD > (it's a "persistence" matter). > > But the main characteristic of them is that they should be inmutable, > which you can easily > achieve by using [1]. > > That same Value Object (for example, an Address) could be referenced by > multiple Entities (being mapped in fact as a 1-n relationship). > > > > http://isis.apache.org/more-advanced-topics/how-to-02-080-How-to-specify-that-none-of-an-object's-members-can-be-modified-or-invoked.html > > > 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). > > > > I fully agree with Dan. I've never tried it, but the theoretical advantage > of JDO over JPA is that it's better for NoSQL databases. > > > HTH, > > Oscar > > > > El 9/12/2014, a las 16:56, Dan Haywood <[email protected]> > escribió: > > > 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 > > > > Óscar Bou Bou > Responsable de Producto > Auditor Jefe de Certificación ISO 27001 en BSI > CISA, CRISC, APMG ISO 20000, ITIL-F > > 902 900 231 / 620 267 520 > http://www.twitter.com/oscarbou > > http://es.linkedin.com/in/oscarbou > > http://www.GesConsultor.com <http://www.gesconsultor.com/> > > > > Este mensaje y los ficheros anexos son confidenciales. Los mismos > contienen información reservada que no puede ser difundida. Si usted ha > recibido este correo por error, tenga la amabilidad de eliminarlo de su > sistema y avisar al remitente mediante reenvío a su dirección electrónica; > no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. > Su dirección de correo electrónico junto a sus datos personales constan en > un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de > mantener el contacto con Ud. Si quiere saber de qué información disponemos > de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un > escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente > dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - > 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). > Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos > adjuntos no contengan virus informáticos, y en caso que los tuvieran > eliminarlos. > > > > > >
