Is MVP really necessary?

Topics: CAB & Smart Client Software Factory
Jan 18, 2006 at 7:24 PM
originally posted by: MarcoPaul

I was wondering how necessary you think it is to following the MVP model when using the CAB framework. Many of our developers are relatively new to OOD and .NET, so I am just worried that not only will learning this new tool hinder our progress at first, but the extra abstraction MVP provides will also cause confusion.

Jan 19, 2006 at 4:41 AM
originally posted by: WalkingDisaster

MVP allows you to optamize the ratio of code that can be unit tested. If you're not planning to unit test, you won't need MVP.
Jan 19, 2006 at 6:41 AM
originally posted by: eichert12

I would strongly urge you to make the investment in learning MVP. It helps to increase the quality of the code your team produces by making it possible to unit test the logic that is contained within your UI.
Jan 19, 2006 at 11:35 AM
originally posted by: dfoderick

And a windows form with thousands of lines of ui, eventing, data access, threading, workflow and business rules is not confusing?
Jan 19, 2006 at 12:28 PM
originally posted by: WalkingDisaster

MVP (and MVC) actually better facilitate reuse of business logic, simplification of model-view interaction, and makes testing easier (as well as creating a formalized interaction between the business logic and view).

I'd say it makes things simpler and less confusing. It's just a matter of learning the pattern(s). Some teams have to focus on quick and dirty over clean and proper. It's a business decision.
Jan 19, 2006 at 3:34 PM
originally posted by: MarcoPaul

"And a windows form with thousands of lines of ui, eventing, data access, threading, workflow and business rules is not confusing?"

Well yes, that is definetly confusing, however, we fortunately do not follow that model. We have a clean seperation between our various layers, with no business logic embedded in our UI components, while implementing many of the GOF patterns where necessary. The question was in regards to adding the extra layer of abstraction. The problem lies in the fact that as of today, I cannot simply clone myself, I need to make sure the other developers are able to stay productive.
Jan 19, 2006 at 8:13 PM
originally posted by: dfoderick

I hate to sound offensive but I really don't understand your situation. You say you are using a well factored component architecture in your UI layer and yet you question the necessity of separating out the model, view, and presenter. The only way you are going to get the first is with the latter.

Is it necessary to separate the visual and non-visual components of the UI? I think so, absolutely! Therefore, you must have separate view and presenter/controller layers in your UI.

It sounds like you need to download the SCBAT. Although in eary alpha, it has templates for creating the necessary base classes when setting up new modules and a reference implementation of CAB. Other than that, there is no substitute for team communication and shared learning.
Jan 20, 2006 at 8:49 AM
originally posted by: JayUrbanowicz

And just where is the SCBAT to download?
Jan 20, 2006 at 9:00 AM
originally posted by: WalkingDisaster
Jan 20, 2006 at 11:35 AM
originally posted by: DarrelMiller

I don't think it is fair to say that if you are not doing MVP then you cannot have a well factored component architecture.

I too am struggling with how to fit my existing model into the CAB + MVP framework. From where I stand I see lots of overlap between the controller and the Work Item. Personally I like my "View" class to be able to pull data from both the controller and the model rather than only allowing data to be pushed in. Yes it casues difficulty with doing unit tests but then I would prefer to do the WATIR style of UI testing where you simulate the clicks and keypresses.

I am also looking forward to see how the CAB team integrate the WF Activity into their framework. The idea of implementing Activites that control Work Items that control Presenters/Controllers seems a little overkill for most scenarios!

Jan 20, 2006 at 6:39 PM
originally posted by: dfoderick

The other reason that the view should be as dumb as possible, besides testability, is that Avalon/WPF/XAML will be here soon. You want to be in a position where when a new technology comes along the surface area that is touched is as small as possible. In other words, the best situation that you can be in when WPF comes out is if the only thing you have to swap out is the view (and maybe a little bit of the presenter but hopefully not much). If you have a bunch of code in the view that reaches down to the controller or workitem then you've got a bunch of work to do. If your view only contains controls and layout then you're golden. The view is very technology specific code; think of it as throw away code. You'd like to hand it over to a UI designer, let them play with it and when it looks good, just drop it in and it just works. If you've got a lot of code in there then you have to worry about them screwing it up and, of course, testing becomes harder.

Its really a simple concept called separation of concerns.
May 29, 2006 at 6:02 AM
originally posted by: derekgreer

While this is an older thread, I just wanted to reiterate some of the points expressed here and add some further comments.

The MVC pattern and all its derivatives are first and foremost about achieving Separation of Concerns (SoC). In general, the benefits of SoC include producing code which is more understandable (albeit apart from the initial learn curve of the patterns used), more easily reused, and easier to maintain (including bug fixing and refactoring).

I would certainly disagree that using the MVP pattern is of no use apart from its unit testing value. Its hard to guess how many people actually write unit test cases for their MVC based code (including frameworks such as Struts, Spring, WebWorks, and the UIPAB), but I would imagine it is a fairly small percentage.

Concerning whether the MVP pattern is necessary to have a well architected application, the MVC pattern is really concerned with the presentation layer of your application which is why the Patterns & Practices' document "Application Architecture for .Net: Designing Applications and Services" depicts and describes the controller (or UIP components) as residing in the presentation layer. The controller/presenter's purpose is to decouple the logic which handles user interaction from the application's views. It is basically the user interaction traffic cop. While the CAB documentation seems to indicate their use of the controller is to “implement the business logic behind the view”, the controller within the MVC pattern doesn't speak to whether a controller implements the business logic of your application or not. Good architects will tell you that you should decouple your domain/business logic from the presentation layer (including any MVC specific implementation). The purpose for this is all the above reasons for SoC. I'm just getting into the CAB examples myself, but one of my criticisms thus far has been that the CAB examples don't separate their components into well defined layers such that the business components may be used by other non-CAB based projects. In my opinion, it's far more important to have a clear separation between your business logic and your presentation layer over having a clear separation between views and their controllers (though I advocate both). That understood, Darrel Miller is correct in stating that “a well factored component architecture” need not follow the MVP pattern. It’s far more important to have a clearly defined presentation layer, business layer, and data access layer than to follow MVC.

Derek Greer