Comments on: Model/View/Presenter and Qt? http://thesmithfam.org/blog/2009/09/27/model-view-presenter-and-qt/ Your blog is probably better than mine. Tue, 07 Sep 2010 02:05:02 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Dave http://thesmithfam.org/blog/2009/09/27/model-view-presenter-and-qt/comment-page-1/#comment-101714 Dave Thu, 29 Apr 2010 20:29:05 +0000 http://thesmithfam.org/blog/?p=407#comment-101714 Another failing of this approach is that the presenter is not injectable and therefore not unit testable. In other words, the "ui" instance on which the presenter operates can not be faked in a unit test. This is one of the advantages to using model/view/presenter and Qt fails to make this possible without some serious work on the part of the developer. Another failing of this approach is that the presenter is not injectable and therefore not unit testable. In other words, the “ui” instance on which the presenter operates can not be faked in a unit test. This is one of the advantages to using model/view/presenter and Qt fails to make this possible without some serious work on the part of the developer.

]]> By: skerr http://thesmithfam.org/blog/2009/09/27/model-view-presenter-and-qt/comment-page-1/#comment-88634 skerr Tue, 29 Sep 2009 23:23:52 +0000 http://thesmithfam.org/blog/?p=407#comment-88634 If you consider your widget subclass to be part of the view instead of the presenter and add another layer of indirection to be the presenter, then you implement the MVP pattern correctly. If you consider your widget subclass to be part of the view instead of the presenter and add another layer of indirection to be the presenter, then you implement the MVP pattern correctly.

]]> By: Dave http://thesmithfam.org/blog/2009/09/27/model-view-presenter-and-qt/comment-page-1/#comment-88549 Dave Mon, 28 Sep 2009 18:22:02 +0000 http://thesmithfam.org/blog/?p=407#comment-88549 Steve, By your definition of MVC, Qt is definitely closer to MVP. Any updates from the model to the view must go through the widget subclass (what I'm tentatively calling the presenter). You *can* connect signals from the model directly to the view, which is convenient, but it seems that most applications apply a little, ahem, presentation logic to the data first. For example, if you have a QLabel in your view, and a model signal that emits textChanged(QString), you *can* connect your model's textChanged() signal directly to your QLabel's setText() slot. This is super convenient, but in practice, you almost always want to do stuff to the data before displaying it (like trim() it or capitalize it or apply some html formatting to it), necessitating a presentation layer between the model and view. On another note, I am very interesting in seeing a Qt MVP implementation that has a totally decoupled view and presenter. Qt seems to encourage the two to be tightly coupled and 1:1 instead of 1:N in relationship. --Dave Steve,

By your definition of MVC, Qt is definitely closer to MVP. Any updates from the model to the view must go through the widget subclass (what I’m tentatively calling the presenter). You *can* connect signals from the model directly to the view, which is convenient, but it seems that most applications apply a little, ahem, presentation logic to the data first.

For example, if you have a QLabel in your view, and a model signal that emits textChanged(QString), you *can* connect your model’s textChanged() signal directly to your QLabel’s setText() slot. This is super convenient, but in practice, you almost always want to do stuff to the data before displaying it (like trim() it or capitalize it or apply some html formatting to it), necessitating a presentation layer between the model and view.

On another note, I am very interesting in seeing a Qt MVP implementation that has a totally decoupled view and presenter. Qt seems to encourage the two to be tightly coupled and 1:1 instead of 1:N in relationship.

–Dave

]]> By: Steven Kerr http://thesmithfam.org/blog/2009/09/27/model-view-presenter-and-qt/comment-page-1/#comment-88500 Steven Kerr Mon, 28 Sep 2009 03:57:40 +0000 http://thesmithfam.org/blog/?p=407#comment-88500 If your Model does not know about your View, than you definitely have a Presenter, not a Controller. In the Model/View/Controller pattern, the Controller is a layer of indirection going from your View to your Model. The data flow looks like this: View->Controller->Model. But, a change in the Model would notify the view directly: Model->View. When the Controller also becomes a layer of indirection going from the Model to the View (Model->Controller->View), the Controller is then promoted to being a Presenter. Not only does it handle user input, but it now also "presents" data. Some will go so far as to keep their Controller and Presenter as separate classes. I personally have not seen a good enough gain in this to warrant the bloat. It looks to me that QT will promote unit testing, which is a big part of the pattern; but, the inability to replace a view without altering the presenter in any way does bring QT's adherence to the pattern into question for me. If your Model does not know about your View, than you definitely have a Presenter, not a Controller. In the Model/View/Controller pattern, the Controller is a layer of indirection going from your View to your Model. The data flow looks like this: View->Controller->Model. But, a change in the Model would notify the view directly: Model->View. When the Controller also becomes a layer of indirection going from the Model to the View (Model->Controller->View), the Controller is then promoted to being a Presenter. Not only does it handle user input, but it now also “presents” data. Some will go so far as to keep their Controller and Presenter as separate classes. I personally have not seen a good enough gain in this to warrant the bloat.
It looks to me that QT will promote unit testing, which is a big part of the pattern; but, the inability to replace a view without altering the presenter in any way does bring QT’s adherence to the pattern into question for me.

]]>