You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by David Tildesley <da...@yahoo.co.nz> on 2015/01/03 22:50:28 UTC
ViewModel documentation update.
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 |
| |
| |
Re: ViewModel documentation update.
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@yahoo.co.nz> 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 <
> davotnz@yahoo.co.nz> 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 |
> | |
> | |
>
>
>
>
>
Re: ViewModel documentation update.
Posted by David Tildesley <da...@yahoo.co.nz>.
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 <da...@yahoo.co.nz> 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 |
| |
| |
Re: ViewModel documentation update.
Posted by David Tildesley <da...@yahoo.co.nz>.
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 <da...@yahoo.co.nz> 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 |
| |
| |