views:

267

answers:

1

We're looking at patterns such as MVP that can help make us seperate UI from logic from data. The initiative is late in the game, but is an effort to begin to set rules that we need to write more testable code (currently we write hairballs, spaghetti, duct-tape and wood screws, etc.)

As we look to the approaches to take with out 2.0 WinForms app we are also keeping WPF and the next-generation of our product's UI in mind. We are trying to create something that should be readily reusable in the WPF world by pulling our WinForms UI/View off and slapping our new WPF UI/View on.

Does any particular pattern for 2.0 development lend itself to naturally slide into WPF's MVVM pattern? What pattern should we follow today that will let us transition into WPF without needing to either hack WPF onto our existing presentation logic or vastly rework/move (again) our presentation logic to fit WPF?

+2  A: 

The MVP pattern will give you that logical separation, but mostly I believe that MVP`s strength lies in writing testable code.

I would recommend reading Uncle Bob`s (Robert C Martin ) book called Agile Principles, Patterns and practices.

Also I believe that you don`t necessarily need to use a pattern like MVP to logically separate your business logic from your UI layer. If properly structured, all your business logic would then reside in a business layer, which is total disconnected from your UI layer. You can then use several interfaces, like WinForms, WebForms or WebService or even WPF, to the same business layer without having to rewrite any business logic, validation, authorization rules ect.

In this case I would recommend reading Rocky Lhotka's book called Expert C# Business Objects. This book is an easy read and he explains how to separate logical layers. Also his goal is to keep UI code to minimum.

MegaByte
Thanks for the suggestions; I've got Uncle Bob's "Clean Code" which I've only started but enlightened me (via an early ugly method converted to a clean class) of how to write methods which truly do one thing, and therefore making writing proper unit tests (which only test one thing) a snap to write.
STW