David, Many thanks for the contribution, good advice. I've updated the page [1] more-or-less exactly.
Cheers Dan [1] http://isis.apache.org/more-advanced-topics/ViewModel.html On 3 January 2015 at 22:06, David Tildesley <[email protected]> wrote: > Hi, > Apologies for Yahoo Mail mangling my reference URLs below. It's a recent > "feature" and I have just figured out it causes a problem and how to > deactivate it. > Anyway, here is another go at the URLs: > [1] http://isis.apache.org/more-advanced-topics/ViewModel.html[2] > http://www.step-10.com/SoftwareDesign/ModellingInColour/dnc.html > > > On Sunday, 4 January 2015 10:53 AM, David Tildesley < > [email protected]> wrote: > > > Hi, > Thought this would be better as a separate thread. There is a current > document page on ISIS wiki [1] describing ISIS "View Model". I think this > is a good description of ISIS "View Model" as it reinforces that you may on > occasion have need of a "View Model" for some UI scenarios but otherwise it > is not the norm. > I would suggest adding the following: > "One of the compelling things about ISIS based applications is that the > cost of the UI/Application layer is zero if you don't make use of 'View > Models'. > So the sensible thing to do with this powerful tool when building > non-trivial business applications is: > (1) Focus on the overall domain model (particularly the shape which in > turn gets influenced by the domain behaviour required - so sorting out the > business behaviour up front with your business subject matter experts > avoids an unsuitable shape that results from a "CRUD" behaviour alone). The > domain model as represented by a UML class/object model should be devoid of > all infrastructure plumbing concerns. > (2) Build the ISIS app with just using Domain Objects taken directly from > the Domain Model only (do not introduce View Models at this crucial stage). > (3) Verify the domain model with the business using the live application > from (2) and adjust as necessary. > (4) Once you have a consensus with the overall domain model then you can > have a discussion with the business about any specialised UI interactions > that might require the use of a View Model or several. > (5) Add as many View Models over time as necessary but don't use these to > compensate for an inadequate Domain Model and don't use them in lieu of a > required extension to the Domain Model (a good domain model shape that more > or less follows Peter Coad's Domain Neutral Component archetypal domain > shape will stand you in good stead for extensibility and longevity). > (6) Never be tempted to put domain logic into View Models. > (7) Never have any of the domain objects dependent on View Models. I.e. > The direction of dependency is one way: The View Models depend on the > Domain Layer." > [1] ViewModels > | | > | | | | | | > | ViewModelsDocs »More Advanced Topics ViewModels In most cases users can > accomplish the business operations they need by invoking actions directly > on domain entities. | > | | > | View on isis.apache.org | Preview by Yahoo | > | | > | | > > [2] Model Archetypes and the Domain Neutral Component > | | > | | | | | | | | > | Model Archetypes and the Domain Neutral ComponentPeter Coad's 'Modeling > in color' defines four class archetypes. A model archetype is a typical > structure of collobaorating classes that guides the rapid constructio... | > | | > | View on www.step-10.com | Preview by Yahoo | > | | > | | > > > > >
