Hi Cesar,
I think you are saying you currently have :
Business - ------> 1..* BusinessLocation
Where one way navigation.
Whereas in the first use case you want two way navigation so it looks like this:
Business 1 <--------> 1..* BusinessLocation
So if you have a BusinessLocation "in focus" then it is associated to single
Business. This two way navigation between objects has always been an "expensive
thing" to build - hence it is normally avoided unless the tradeoff suggests it
should be done - but maybe ISIS makes this easier.
But it sounds like you want a view which consolidates the information from one
graph instance of the above into a single "form". So I believe the correct
answer is yes: that is what the View Model is for. In terms of update behaviour
- you need to add the operation on the View Model that explicitly sets the
values on the domain object graph and persists them - I would suggest a single
operation on Business for that purpose because Business should know about it's
BusinessLocations - you pass the user values in including the
BusinessLocation.id because Business has to know which BusinessLocation to
update.
Put all your View models in a separate package - they are not part of the
domain. Make sure all the domain behaviour belongs to the domain objects and
doesn't leak out into View objects. Never reference a View Model from the
Domain Model the dependency should be View --> Domain and never the other way
around. Domain is stable, View is volatile. Just create as many View Models as
you need for the UI - after all that is what they are for. In fact your
application may not need to expose any domain objects as naked objects - but
then again, there may some user experience downside to that (e.g. having to
explicit operation for update).
Folk - correct me if I am wrong - I need to catch up with where ISIS is
currently at and so having folk correct me is very welcome for my education.
Regards,David.
On Friday, 6 November 2015 4:16 AM, Cesar Lugo <cesar.l...@sisorg.com.mx>
wrote:
Hello. I have the need to create some objects that are compound from some
other domain objects (similar to a "view" in a relational database,
updatable views). Let's say I have Business with businessId and name
properties, 1:n to another entity named BusinessLocation with properties
businessLocationId and name and address properties (to keep things simple
for now). So, for example, I need to create a new object that is
BuisinessLocationView, which contains BuinessLocation.id,
BusinessLocation.name, Business.id and Buiness.name . Then, in some cases, I
want to use such views like BusinessLocationView as a collection within
Business, and as a standalone collection, and also have the ability to
update its fields so the corresponding entities are updated with the changes
(Business and BusinessLocation), and in some cases even add a new view like
BusinessLocationView so it adds a new BusinessLocation.
Is there a way to do this? Is that what @ViewModel is for?
I would appreciate If you could point me to any sample that might help.
Cesar.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
