Just one question.
Currently, the interface seems to be mandatory only for generating the OID.
That "forces" the framework to not being able to use "plain" POJOs as view models, as all them must implement that interface.
If, when the interface is not implemented by the entity, the OID would be generated as "some useful" combination of the class and a hash, any "non-JDO managed" class could be returned from an action and being properly managed by the viewers, etc.
Could it be possible?
I'm sure I'm missing other requirements, but prefer to launch the question, as not allowing any class to be returned by an action (obviously, non-editable) has always disturbed me, and seems related.
Thanks,
Oscar
El 20/03/2014, a las 16:59, Dan Haywood <[email protected]> escribió:
David said:
Some more thoughts/assumptions on transient domain objects:
1. oid - annotate an attribute or use attribute naming pattern
2. Restful remoting mean client maintains required state - client doesn't
care whether domain object is transient or not.
3. Restful remoting means the server trashes the domain object instance
after the response. However domain behaviour is not transferred and
everytime a behaviour is invoked on a domain object graph, the domain graph
has to re-instantiated at the server - big performance hit unless
developer uses a cache (ehcache or similar).
Am I wide of the mark with any of the above?
Jeroen said:
I do agree with David that there are plenty of use cases to think of where
having a transient domain object on the server can be useful. I am
wondering how comparable architectures deal with transient objects, perhaps
an analogy with a Stateful Session Bean can be made? [1]. This would make a
good topic of conversation on the IsisCon conference too.
[1] http://www.jguru.com/faq/view.jsp?EID=917
And on 19 March 2014 21:29, David Tildesley <[email protected]> also
said:
Maybe "transient" is misleading in my side of the discussion. Essentially
a viewer should be able to instantiate an ISIS domain object that has no
connection to DataNucleus, repository as such but can still have a domain
service implementation fetch and put data from an external source (via,
web-service, jms, whatever) and inject into the domain object. That keeps
my domain layer intact and doesn't result in bleeding any domain behaviour
out to other layers (e.g. view objects which are logically in the UI layer).
However as Dan points out, this doesn't sit well with RESTful style. In a
traditional app, UI layer (usually using a MVC model) will make several
invocations on domain object graph behaviour (fine grained method level
calls) with state being maintained in the session for as long as needed
over a series of client requests. This is not the case with RESTful style.
Client is responsible for maintaining state with the server having no
obligations in this regard. This does not sit well with a fine-grained
method invocation on the domain layer - you would normally go for those big
coarse grained calls and end up re-implementing a domain layer in the
client that replicates domain behaviour. This is where the RESTful model
falls into a heap (in my opinion) as the tradeoff is very significant. To
retain the "finegrained" domain layer invocation on the server side in the
RESTful style would necessitate rebuilding the relevant domain object graph
with every call
and trashing it afterwards. This rebuilding "hit" could be mitigated by
careful use of caching on the domain service layer, however the lifecycle
of the domain object graph has to be completed on every RESTful invocation.
There's quite a few subtle points here to discuss.
One thing to say first off, perhaps "view model" also is not the right term
for what we have in Isis; it suggests that the object is only for
presentation purposes, but in fact it could be used as an entity that is
managed externally too. In fact, over in Ireland on the "sister" .NET
project, we are doing something very similar to this with the equivalent
functionality provided by NO MVC.
Anyway... I understand the objection loud and clear about not having to be
forced to use DataNucleus to obtain entities. And I also hear what you are
saying about REST and it moving all the state management client-side into
the viewer. Obviously this isn't the intention; we want the domain logic
to be expressed only in one place, namely in Isis. This is non-negotiable,
we're not trying to build something like EmberJS.
To answer the REST point briefly: the standard pattern is to have some sort
of (server-side) resource that represents the conversation/transaction.
This is analogous to Jeroen's point about stateful session beans. I'll
come back to this in a moment.
Let me get back to the main point about using Isis for domain objects whose
persistence is managed by some other mechanism. I think that our (perhaps
misnamed) ViewModel mechanism will actually work quite well here; the
viewModelMemento() method / viewModelInit(String) methods provide a simple
mechanism by which the view model provide/gets a handle to the external
object. (The memento is basically the Oid, as I've said).
And so, for example, it'd be trivial to implement stateful session beans
using this mechanism:
- we have a domain service that wraps the HttpSession interface.
- a view model is created and generates a GUID as its memento. It uses
this GUID to store its state into the HttpSession through the domain
service.
- when the view model is recreated and init'd with that same GUID, it uses
the GUID to fetch its state from the domain service. At the end of the
interaction, it flushes any changes back to the domain service.
One thing to note is that a view models OID is immutable. However, all
that means is that the GUID it uses to fetch from the externally-managed
resource (eg HttpSession) doesn't change; the state keyed by that GUID
*could* change.
I'm pretty sure that the same general design can work for any other
externally-managed entity; so long as we have a unique identifier to it,
this can be the memento given to the view model. Logically speaking this
view model is acting like an entity to the rest of the domain objects in
the Isis app; its just a wrapper around that externally-managed entity.
As I say, ViewModel is probably the wrong name/gives the wrong impression.
(Unless one consider it to be the view not of the Isis app but of the
external system, which I suppose is true.... a sort of anti-corruption
layer).
All the above notwithstanding, it is worth noting that by ignoring
DataNucleus there are a few things that one would not get:
- dirty tracking, and automatic saving/persistence
- lazy loading
- querying
- auditing and object publishing (both of which leverages DataNucleus'
dirty tracking).
So I still think it'd be worth considering wrapping up a domain service as
a DN StoreManager impl. I imagine that a lot of the boilerplate could be
factored out. Just looking at the datanucleus-json implementation of
StoreManager [1], for example, it doesn't look *too* threatening. I also
noticed that DataNucleus has a FederatedStoreManager, so there could be a
number of companion store managers for managing entities from these
external systems, operating alongside any entities that Isis itself manages
in the regular JDO ObjectStore.
To summarize:
- objects that implement Isis' ViewModel interface can be considered to be
entities if they are basically proxies to externally-managed entities
- but doing it this way means that a lot of the features of the ORM must be
re-implemented by hand.
Let's keep talking on this thread, it's useful and fundamental stuff
Dan
[1]
https://github.com/datanucleus/datanucleus-json/tree/master/src/java/org/datanucleus/store/json
Ó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
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.
|
