On 9 November 2015 at 19:11, Cesar Lugo <cesar.l...@sisorg.com.mx> wrote:
> Dan, this statement you made cached my attention, s/cached/caught > as it might help reduce foreign keys and make the application more > maintainable: > It doesn't reduce them, but it does move them out of the "child" table and into the join table. > > "I prefer to use a join table for unidirectional, but FK for > bidirectional; that way the database tables model the domain classes quite > nicely (in particular, with a unidirectional and a join table the child > table doesn't "know" about its parent)." > > How can I implement this with Isis / Datanucleous? > > http://www.datanucleus.org/products/accessplatform/jdo/orm/one_to_many_collection.html > Cesar. > > -----Original Message----- > From: Dan Haywood [mailto:d...@haywood-associates.co.uk] > Sent: Friday, November 6, 2015 2:03 AM > To: users; David Tildesley > Subject: Re: Compuond objects > > Hi David, > thanks for chipping in on this thread. To answer your last question, I > think I agree very broadly with your analysis. More detail within... > > > On 5 November 2015 at 20:08, David Tildesley <davo...@yahoo.co.nz> wrote: > > > 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. > > > > With JDO/DataNucleus, bidirectional relationships are no more difficult > than unidirectional. With both bidirectional and undirectional, DN > supports either using a join table to hold the tuples between parent/child, > or alternatively a more traditional FK in the child. I prefer to use a > join table for unidirectional, but FK for bidirectional; that way the > database tables model the domain classes quite nicely (in particular, with > a unidirectional and a join table the child table doesn't "know" about its > parent). > > > > > 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. > > > What you are saying is true in this case, but you'll remember a long > thread from about a year ago when we enumerated various different "types" > of view model. We came to the conclusion that the view model > implementation is also appropriate for what are really domain entities that > just happen to be persisted externally, eg over a SOAP service. > > We express this using the @DomainObject(nature=...) attribute [1] > > > > > 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. > > > > As per. If you're just catching up, check out: > > - changes to Isis itself in the release notes [2] ; 1.10.0 is imminent. > - (non ASF) Isis addons, [3] - for reusable cross-cutting concerns > - (non ASF) incode catalog, [4] - for reusable business functionality > > > > > Regards,David. > > > > > > > Thx > Dan > > > [1] > > http://isis.apache.org/guides/rg.html#_rg_annotations_manpage-DomainObject_nature > [2] http://isis.apache.org/release-notes.html > [3] http://www.isisaddons.org/ > [4] http://catalog.incode.org/ > > > > > > > > > > > > > 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 > > > > > > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > >
