On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o....@gesconsultor.com> wrote:
> Ok. > > So let's raise some questions/doubts :) > > *** @DomainObject *** > > Is a ViewModel a DomainObject at all ? > > it's a good question, and I've debated it myself. Let me lay out my thinking on this so far and see if we can collectively come to a view on this. First thing to note is that there are two "varieties" of view models (even though the implementation is identical) - those that are part of the domain layer and are, conceptually at least, entities, but where the persistence is managed outside of Isis. An example is a document in a CMS - those that are part of the application layer, and represent a view on top of one or more entities. Of course, we expect an application layer to depend on the domain layer and not vice versa, but even so, because some view models are conceptually entities I suspect that in a typical Isis application it will be reasonable to allow JDO-managed domain entities to interact with externally-managed view model entities. Because of this, I've been thinking of "DomainObject" as being a superset of both entities and view models. > I would consider them as a different kind, so the @ViewModel annotation > shouldn't be deleted. > You are certainly right that quite a few of the features in @DomainObject don't apply to view models (even if conceptually they are entities)... because we rely on JDO to implement. Specifically: - auditing... requires JDO so doesn't apply to view models - publishing ... requires JDO so doesn't apply to view models - bounded = not sure... even though doesn't depend on JDO, suspect that it isn't supported for view models - autoComplete ... is supported for view models - editing ... is supported so long as the ViewModel.Cloneable interface is also implemented. I can foresee this restriction being lifted in the future - objectType ... is supported for view models (used as REST URLs) > Also, perhaps we can introduce Isis platform logic like not > "saving/persisting" view models, etc. If that would be the case, the > "editing" and "editingDisabledReason" at least might not have any sense. > > Not sure I understand this point. But at any rate, given that some view models are basically externally-managed entities, the semantics of "saving/persisting" would also apply. > > If so, I would better align with DDD naming conventions, in order to gain > acceptance. > > So, names should be @Entity or @DomainEntity (for avoiding name collision > with JPA) - instead of @DomainObject -. > > I did consider @DomainEntity, but as I say, sometimes view models act like entities. I do quite like it though. I have a counter-proposal, see below. > I like the @DomainService name, as it can act as a DDD Factory and/or > Repository. > > > As currently there's no "special" support for AggregateRoots or > ValueObjects, no more annotations are needed. > > Sounds like a vote to deprecate. Jeroen has said the same thing. Perhaps they should be deleted in v2.0 and reappear, if we want them back, in v3.0. > So the proposed set would be: > • @ViewModel and @ViewModelLayout > • @DomainService and @DomainServiceLayout > • @DomainEntity and @DomainEntityLayout > • @Property and @PropertyLayout > • @Collection and @CollectionLayout > • @Action and @ActionLayout > • @Parameter and @ParameterLayout > > > Here's my counter-proposal. It's not as symmetrical as before, but perhaps is less confusing overall: * replace @DomainObject(viewModel=false) with @DomainEntity(persistence=JDO) ... this would be the default * replace @DomainObject(viewModel=true) with @DomainEntity(persistence=EXTERNAL) ... for view models representing externally-persisted entities. In the Javadoc, say that auditing, publishing and bounded are not supported for these * keep @ViewModel ... extend to include the non-entity stuff from @DomainObject that does apply (basically, I think that's just "objectType" ) ... the intention being that this is used for application-layer views. keep @DomainObjectLayout, because everything in it applies equally to both view models (either variety) and JDO entities. I'll reply on your points on @Property and @Parameter separately. Thx Dan >
