Design Patterns in ZK: Java MVVM as Model-View-Binder
Download as odp, pdf13 likes13,368 views
This document discusses different patterns for separating the view, model, and controller/presenter layers in a ZK application. It describes the MVP, MVC, and MVVM/MVB patterns and compares their approaches. It provides best practices for implementing each layer, such as avoiding business logic in the view and using databinding to sync the view and model. The document emphasizes that the view model pattern focuses on separating application state and behavior from the view using databinding annotations.
![Programming In The View
Business state stored in
view
<label id=”hiddenBookId” value=”${book.id}” visible=”false”/>
<button label=”Buy Book”>
View knows 'who' and
<attribute name=”onClick”><![CDATA[
'how'
MyDao myDao = … ; // get daoand render mixed
Update via jndi
myDao.buyBook(user.id, hiddenBookId.value);
statusLabel.value = ”Thanks! Buy another book?”;
]]></attribute>
</button>
<label id=”statusLabel” value=””/>](https://cdn.statically.io/img/image.slidesharecdn.com/zk-mvvm-110409153944-phpapp02/85/Design-Patterns-in-ZK-Java-MVVM-as-Model-View-Binder-6-320.jpg)
More Related Content
What's hot (20)
Viewers also liked (12)
Similar to Design Patterns in ZK: Java MVVM as Model-View-Binder (20)
Recently uploaded (20)
Design Patterns in ZK: Java MVVM as Model-View-Binder
- 1. Presentation Patterns In ZK Simon Massey (Revised Q2 2012)
- 2. Introduction First version of this presentation was given to the 2010 UK ZK Users Group The "ZK ToDo 2" patterns sample code is in the zkforge project svn repository github.com Sample code has the same screen implimented three times; as MVP, MVC and MVVM (MVB) Published articles document the MVP and MVC versions. Article coming soon about MVVM... See references at the end
- 3. Overview Why Patterns? Patterns recap of View and Model Model, View, Who? The third part Best practices for each layer
- 4. Why Patterns? Evolving Software A business sponsor talks about the screens but requires a flexible business solution Screens are likely to change all the way through to go-live and well beyond Features evolve slowly over time whilst the screens can change drastically Can you easily reskin / re-layout / rearrange your app to freshen your user experience? Making flexible and adaptable solutions is more rewarding than making brittle apps
- 5. Why Patterns? A Challenge! Reuse a "buy now" feature of your website in an iphone app (as XML over HTTP) This requires separation of View from Model
- 6. Programming In The View Business state stored in view <label id=”hiddenBookId” value=”${book.id}” visible=”false”/> <button label=”Buy Book”> View knows 'who' and <attribute name=”onClick”><![CDATA[ 'how' MyDao myDao = … ; // get daoand render mixed Update via jndi myDao.buyBook(user.id, hiddenBookId.value); statusLabel.value = ”Thanks! Buy another book?”; ]]></attribute> </button> <label id=”statusLabel” value=””/>
- 7. Avoid Coding In The View "Separated Presentation” is a core pattern Presentation is incidental to what the customer is logically doing which is the Use Case / User Story (e.g. "customer buys book") The presentation changes fast and often so separate it out from the business logic Junit testing of the presentation is tricky Business logic within the View stunts the flexibility of your software design
- 8. The Triumvirate View Model who?
- 9. Micro vs. Macro Much of the literature about MVC describes the fine grained "micro-MVC" used to implement graphical components such as Swing/JSF When reading articles it helps to think "Is this micro-MVC or macro-MVC?" This century we tend to pick a winning UI component framework (ZK!) and focus on "macro-MVC" for complex business screens This presentation talks about the macro world unless explicitly stated
- 10. The View View Model who?
- 11. View Best Practices "ZK Desktop == View" so mixing Java business logic into ZK code is mixing business logic into the View View components should not become business components: BuyNowButton extends Button // avoid! The View should observe the Model using the databinder (more on this later): org.zkoss.zkplus.databind.AnnotateDataBinder
- 12. View Has Micro Models A BindingModel is an "push through" to update the View. Writing to it updates the bound View These micro models are not business domain models which organise application features ListModelList is binding model class for Listbox listModelList = (ListModelList)listbox.getModel(); AnnotateDataBinder uses such micro-models as part of its logic to sync data into the View Intbox and Datebox have "value" property as micro-Model as well as "visible" and "disabled"
- 13. ZK Micro-Model == View Listbox Composer ListModelList (view layer) Collection<Book> books (business domain layer)
- 14. The Business Domain (Macro) Model View Model who?
- 15. Model Best Practices The Business Domain Model should have no compile time dependencies to the presentation framework EL and AnnotateDataBinder should load data from the Model into the View (avoid coding) Ideally the Model should be a rich Domain Model have both behaviour as well as state Beware designs of proceedural code loading and saving DTOs as this is weak OO Try test driven development of encapsulated layers ("POJOs In Action" book)
- 16. The Other Bit... View Model who?
- 17. Alphabet Soup MVC: Model-View-Controller Often cited but do we really know it as well as we believe? MVP: Model-View-Presenter A specialism of MVC with a dominant controller MVVM: Model-View-ViewModel The Microsoft WPF pattern of the Application Model but how do we use it with ZK? MVB: Model-View-Binder A clearer moniker for "MVVM" with ZK
- 18. MVC Has Many Interpretations Martin Fowler: Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. Anon on c2.com: Stuff nearest the User becomes the View, stuff nearest the database becomes the Model, stuff in between becomes the Controller. Marketects then refer to their project's architecture as "MVC", borrowing that acronym's impressive lineage(!!!)
- 19. Controller Of What? View ? ? Model ? Controller
- 20. The Controller Revisited Typically org.zkoss.zk.ui.util.Composer but what are it's responsibilities? Does Controller read/write the Model? Yes Does Controller read/write the View? Perhaps Does View read/write the Model? Possibly Is separation of behaviour (Controller) from state (Model) the only game in town? No Is databinding with AnnotateDataBinder part View, part Controller, or a separate thing?
- 21. Model-View-ZKComposer org.zkoss.zk.ui.util.Composer usually used as the 3rd part of the pattern Whether it is a Controller or a Presenter depends on the interactions with View and Model: Presenter – pushes to Passive View Controller – updates a model observed by the View ("Supervising Controller") Any mix or match of the above will be called MVC. People say "traditional MVC" to mean View observes the Model updated by Controller
- 22. Model-View-Presenter Legend compiles to View events Model Presenter
- 23. Model-View-Presenter The View is the fully owned by the Presenter ZkToDoControllerV1 implements Composer Pushes all updates into the Passive View ZkToDoControllerV1 implements ListitemRender Presenter reacts to View Event notifications and updates the Model ZkToDo2 app example zktodo2_a.zul For code write-up google "Massey Small Talks/2008/ November/ZK "
- 24. Model-View-Controller Legend compiles to View bindings events Model Controller
- 25. Enter The Binder View observes the state of the Model using databinding <?init class=”org.zkoss.....AnnotateDataBinderInit”?> Uses EL annotations within the ZUL page <textbox value=”@{person.firstname}”/> The @{pojo.property} annotations automatically reads/write your POJOs (no UI event handling code required as ZK Binder does the work automatically!) Google "site:dzone.com mvc zk massey"
- 26. Controller Best Practices Aim to have the Controller and View not communicate with one another. Let the binder to the work Have the binder pull the data from the Model with load hints rather than having the composer push data into the view model <textbox value=”@{person.firstname, load-after='buyButton.onClick'}”/> zktodo2_b.zul example should have used more 'load-after' hints and less Java code (see weather-station-mvvm.zul)
- 27. Model-View-ViewModel ViewModel (Microsoft) is similar to an ApplicationModel (Smalltalk) Binder syncs application state into the View Binder maps View Events onto application methods (ICommand types in .Net C#) Gather both state and behaviour into one application model (stronger OO design) Binder is part of the View world. The application model is its model: so called it a "ViewModel"
- 28. ViewModel Nirvāna Josh Smith (msdn.microsoft.com): "ViewModel classes are easy to unit test … Views and unit tests are just two different types of ViewModel consumers" "ViewModel classes can assist in properly designing user interfaces that are easy to skin" "It is easy to just rip one view out and drop in a new view to render a ViewModel" It's all about the Binder. The name Model-View- Binder (MVB) highlights the key part
- 29. Model-View-Binder (Simplified) Legend View compiles to updates Binder loads <<reflection>> Application Model (has internal layers)
- 30. Model-View-Binder View Binder <<reflection>> Legend ViewModel compiles to command DomainModel load
- 31. Model-View-ZKBind Components are bound to ViewModel by the Binder: <listcell label="@load(reminder.name)"/> UI Events are dispatched to ViewModel methods by the Binder: <button label="Save" onClick="@command('save')"/ > ViewModel has annotations to inform Binder of any properties changed under the covers @NotifyChange({"reminders","selectedReminder"}) public void save() { … }
- 32. MVB/MVVM Best Practices View Model has no references to View Objects only @Command and @NotifyChange annotations Create ViewModel classes which are "naked screens" onto which you overlay a zul skin ViewModel is the Mediator of the Binder to the Model; it orchestrates the services Use Dependency Injection of service interfaces into the View Mode ViewModel uses application services to get detached entites which it exposes to the Binder
- 33. Summary Presentation patterns are all about modelling the features of our application independently of the frequently changing screens MVC, MVP, MVVM all have in common a separated view Modelling of the Model will lead to internal layers Labels such as "ViewModel" or "DataModel" or "ApplicationModel" are suggestions as to what is trying to be organised where
- 34. Summary (Cont 1) "B" is for Binder which plays a big part in MVC and major part of MVVM patterns. There is no "B" required for MVP The Microsoft Binder is powerful and a core part of their framework. They invented MVVM as the best practice to organise a screen Model to leverage their Binder MVB is a moniker that names the new power in modern Separated View patterns: long live the Binder!
- 35. Summary (Cont 2) ZK has a mature AnnotateDataBinder for rendering POJO data values and state (visible/disabled) into ZK AJAX RIA Desktop Components The binding information is embedded into the Page (View) as "XML annotations" Add ZKToDo2 CommandBinder to fire application methods on the ViewModel ViewModel has no compile time dependencies on ZK framework; can heavily junit with mock services Using MVVM / MVB pattern is simply about getting the most out of the framework Binder
- 36. Summary (Cont 3) ZkToDo patterns demo code implements the same screen in each of MVP (zktodo_a.zul), MVC (zktodo_b.zul) and MVVM (zktodo_e.zul)
- 37. References MVC article Desktop MVC Patterns ZK, Spring & JPA Original MVP article SmallTalks 2008 Best MVC Patterns Book on how to build a layered domain model with Spring POJOs In Action ZK MVC Screen for POJOs In Action book code Test Driving ZK FoodToGo Book on designing ”domain objects first” for supple code Evans Domain Driven Design Martin Fowler GUI Patterns pages UI Architectures Josh Smith's inspirational Microsoft .Net MVVM Article
- 38. Corrections March 2012: Slide 13 had totally miss attributed Fowler where I was using the term "Presentation Model" to mean something totally different. Edited to call my concept "BindingModel" March 212: Slide 21 had miss labelled Passive View as Supervising Controller