I am using ZK Framework right now in one of my application. ZK Framework supports MVC as well as MVVM design pattern. Now for a new project I would like to use JSF. Does JSF support the both the design patterns or only MVC?
-
1If you mean "can I separate my managed beans into beans that pertain to UI concerns (View Model) and beans that contain only business logic (Model)" then I would say yes. ā McDowell Nov 13 '13 at 12:02
2 Answers
No, MVVM design pattern not supported by jsf only MVC support.It is used only desktop application.JSF also know as MVC fremework.
From http://blog.oio.de/2011/12/05/jsf-and-mvvm/:
The first M in MVVM stands for Model, and it is the very same model that we use in our MVC approach. In fact MVVM does not replace MVC, I rather prefer to see it as an additon to MVC, so there is nothing new here.
The first V in MVVM stands for View and again, there is nothing new to this part. It is the component that takes care of the client side representation. So there wont be any notable change to our views since we will continue to define them using Facelets.
VM in MVVM stands for the ViewModel, our client side model. The ViewModel is bound to the Model but it is exisitent only on the client side, though you are free to sync it whenever needed with the Model on the server side. But, more important is, that you can do whatever you want on the client side without having to send callbacks to the server.
First of all we need a next-generation-JSF-implementation, which supports the MVVM concept. The ViewModel would be created by this yet to come JSF implementation before a requested view is delivered to the client. Our ViewModel will be created from one or more JSF Managed Beans that form the Model. I can think of a nice set of class- and field-level annotations to tell JSF what parts of our model should make up the ViewModel on the client side. Once the view is delivered to the client, the ViewModel will be manipulated by client side scripts upon the form is submitted. Then, in the following iteration of the request processing lifecycle, JSF has to deal with resynchronization between ViewModel and Model. Admittedly, this might be the most tricky part, but Iām confident that the Next-Gen JSF Impl will manage to do that ;-)
From Understanding JSF as a MVC framework:
The nodes M, V and C are a maximum connected graph, meaning each part can communicate with every other part. E.g. if the model changes, it can push this change to the view. This is particularly visible in case there are multiple representations of the view in a desktop application. Change one, and see the other update in real-time.
Due to the client/server and request/response nature of web applications, classic MVC doesn't map 1:1 to most web frameworks.
More information find this link: http://www.tutorialspoint.com/jsf/jsf_architecture.htm

- 1
- 1
-
2In future answers wherein you copypaste complete blocks of text from external sources instead of using your own words, you should put them in citation blocks, otherwise you may be [accused for plagiarism](http://meta.stackexchange.com/questions/160077/ive-been-accused-of-plagiarism-what-do-i-do). ā BalusC Nov 13 '13 at 10:16
I disagree with user2860053's answer because it makes unnecessary assumptions about MVVM. MVVM is not about client and server responsibilities. The blog post cited only argues that a specific web application scenario involving a combination of client-side MVVM (as implementend by knockout.js) with server-side MVVM doesn't work well with JSF. It doesn't say anything about server-side MVVM.
In my understanding (which IMO corresponds to the original definition that is also referred to by the ZK documentation), the core ideas of MVVM are:
- a) to keep a distinction between the UI's concrete structure, controls and layout (i.e. the view) and its state and behaviour (i.e. the viewmodel), and
- b) link these using a two-way data binding.
Figuratively speaking, starting from "MVC", part a) adds the "VM", and part b) removes the "C" so we yield "MVVM":
In MVC, the controller is written for a specific view class/interface, and it's the controller's responsibility to read user input from the view, convert it and write it to the model, and to invoke business logic according to the user's action.
In contrast, MVVM doesn't have any controllers that are tightly coupled with view or model. Instead, there is a generic mechanism which uses declarative two-way data bindings for filling the view with data and converting user input and feeding it to the model, and for binding controls to business code (or presentation-only actions from the viewmodel).
So how does this apply to JSF?
In JSF, you don't write a controller for every Facelets page you write, but let the JSF lifecycle do the work of filling model elements with data from submitted forms and invoking methods according to the user's actions according to EL bindings, so the second property b) always holds for JSF.
As for the first property a), it's up to the programmer to implement high-level view state and behaviour in separate classes. JSF puts more focus on creating components for view state and behaviour. Viewmodels are made specifically for one kind of view, and model the whole abstract state and behaviour of the view, so I think that even "light-weight" composite components are too generic to take the role of a viewmodel. But there is nothing to prevent the developer from creating his own classes for this, i.e. write one's own viewmodel classes and bind them in the EL context.
In conclusion, JSF is not made specifically for MVVM, but contains mechanisms that can be used for implementing (server-side) MVVM.

- 1,725
- 14
- 24