Mmmm... I understand those arguments. Just for doing a "lateral thinking exercise" and question the current status, I'm going to question some things :-)
In practice, if taken until the end, what that would implied, is: - that we should remove the Isis' @Optional annotation (among others). - that we would implement some Facets for the meta-model that would not have a corresponding Isis annotation (so the Isis "metadata" would not be "complete" in terms of its own meta-model). - that we are always going to use on Isis webapps JDO as the ORM metadata (if one decision criteria is "number of developers" it will be important to support JPA in the future), - that we are always going to use on Isis webapps DN as an object store (I'm happy with this right now), - that we are always going to use on Isis webapps an object store in our apps, and use cases where it's not present would not be "Isis" use cases (unless we mark all entities as transient or something like that; not clear to me...). For example, we have an IT Real-time Monitoring Bounded Context where we want to use Isis. On that BC we would not have available those Isis features (whatever they will be in the future). My opinion, a corresponding Isis annotation would be needed for any Facet, but to be concrete: - for Facets that change the domain's behavior (such as the managed relationships; my code is becoming full of "flush()'es" just for updating the parent collection's size; this could be managed by Isis instead of delegating to DN). - for Facets corresponding to behaviors delegated to one adapter's implementation that will be maintained "as-is" that can be required to be known by other adapters (such as mandatory properties, or imagine that we apply some bean validations on the UI for avoiding network traffic, so the UI would need "access" through the meta-model to those validations, etc.). But this is "just" a theroretical discussion regarding a "long-term" vision. Perhaps the KISS principle dictates to avoid any functionality "duplication". So it's also interesting to consider the costs to avoid previous handicaps, that I think would be: - in terms of implementation, simply to have an Isis annotation for specifying the Facet's behavior. - in terms of maintainability, update it when the Facet behavior changes (that would imply also a change on the adapter that implements the delegated behavior - i.e. the objectstore or any other "adapter" that provides it -). Perhaps they would be manageable for most cases, and we could align with the (at least my) vision. Thanks, Oscar El 09/09/2013, a las 08:55, Dan Haywood <[email protected]> escribió: > On 8 September 2013 11:55, Kevin Meyer - KMZ <[email protected]> wrote: > >>> I must admit that was one of our expectations when we firstly >>> approximated Isis, perhaps because we were following the email list >>> or saw the SQL Objectstore, etc. >>> >>> In fact, seems that recently we have taken the opposite path (by >>> requiring nearly all Entity properties to be annotated with >>> @Column(allowsNull="true|false"), instead of improving the JDO >>> Object Store usage of the Isis meta-model. >> >> When I first started with Isis (when it was still Naked Objects), I was >> really drawn to the fact that any POJO that I prototyped could be >> re-used "as is" elsewhere, as it contained no "framework" clutter. >> >> As Oscar says, this is now exactly the opposite. If the assumption is >> that Isis will always be the deployment framework, this is just fine! >> >>> But we cannot expected to map/solve all ORM requirements on the Isis >>> metamodel, so the end situation will be some inferred, some >>> explicited for sure. >> >> In the SQL OS, I provided for "hints" to be specified in the properties >> file (overriding property-field mappings, table naming, etc) (and >> Eclipse could handle refactoring/renaming if the full name name was >> used in the properties file) - leaving the POJO clean of DB clutter. >> >> > Yes, it's true that we now have the Isis metadata as secondary to the JDO > annotations. > > This breaks symmetry and means that, to deploy Isis against a different > ObjectStore, that at best those JDO annotations are redundant, at worst one > that one would have put in equivalent metadata for the other OS (eg SQL OS' > properties). > > As mentioned, we could invert this. Using the DataNucleus metadata API > [1], we could programmatically build up the DataNucleus metamodel from the > Isis metamodel. Where required, we could also recognize some subset of the > JDO annotations that have no Isis equivalent (eg "mappedBy" for > bidirectional annotations). Or, I suppose, we could add in our own > equivalent Isis annotations. > > I'm not convinced that this is the right thing to do though, for two > reasons: > > 1. there are many potential users out there that understand JDO (and JPA, > of course, when we get around to support it's annotations). Requiring them > to learn the Isis equivalents is going to put them off. > > 2. I don't think that being able to switch between object stores is that > significant. While presentation/UIs are fashion items that change every > few years, the data in a production database tends to stay where it is. > Indeed, the application/domain model itself is more volatile than the > data; right now over in Ireland we are building a replacement naked objects > app to the original, against the same physical DB schema, but with a > changed domain model in certain cases. > > Putting my cards on the table, I would rather that Isis leverage > DataNucleus for handling different persistence mechanisms through DN's own > StoreManager API [2]. Using Oscar's terminology, DN's goal is to provide > the ports and adapters (of the hexagonal architecture) for persistence, > while Isis handles the the ports and adapters everything else > (presentation/UI in particular). > > What I also want to do, long term, is to deprecate all the other Isis > object stores and eventually remove them. We could then start to simplify > Isis internally. > > Obviously, this is for the community to decide on this, but it's where I > currently stand. > > It's worth noting that on Naked Objects.NET, they are following an > equivalent path, where they just use an ObjectStore based on Microsoft's > Entity Framework. In fact, they are going further: where there is an EF > metadata annotation, they are deprecating their NO-specific one. They have > also already dumped all their other object stores bar their in-memory > object store. > > Thx > Dan > > [1] http://www.datanucleus.org/products/datanucleus/jdo/metadata_api.html > [2] http://www.datanucleus.org/extensions/store_manager.html
