Many applications do nothing to separate the interface from domain logic. I’ve been programming for a couple decades and have worked at more than a dozen shops and none of them have taken any measure of separating the interface from the domain logic. That is, they’re all using the Autonomous View pattern. This runs counter to all the wisdom I’ve read about separating concerns. When the user needs to choose an item from a set of items, that selection is directly tied to a combo box rather than an abstraction.
A huge drawback with all this coupling is that it makes it impossible to write unit tests. To run any unit tests the application in its entirety must first be loaded. In my mind, the use case should be encapsulated within an abstraction that can later have a database and an interface attached to it. This kind of separation would make implementing unit tests trivial by comparison.
Given that the average shop has its interface and domain logic tightly coupled, how to we refactor to separation? That is, a complete rewrite is off the table. What I’m talking about is taking a proposal to management about how to go about creating domain objects (whatever these happen to look like) that live in isolation from the database and the interface. In other words, it would be useful to be able to explain how this concept of presenting the user with a choice (something that is now represented by combos on forms) and to see how some methodology/framework/pattern represents that in an abstract sense and how that abstraction is then tied to the interface. This would make replacing combos with listboxes nothing more than a slight detail.
What are some good ways for extracting abstractions (domain use cases) from forms? Any good online resources? My current shop is on .NET, though I am interested in ideas from any development platform. Ultimately, what I need to provide is a concrete example (code) of how this might be accomplished.
6
There are a variety of presentation patterns whose exact role is to split out the interface from the behaviour.
Since you specifically mention a Microsoft environment, I would recommend you look up MVVM (which is promoted with particular reference to WPF) and MVC (which is promoted re ASP.NET). Microsoft’s MVC approach is a physical framework based closely on the generic MVC pattern – it breaks a few abstractions but auto-produces code for you.
A further approach, also promoted by Microsoft until they jumped on the WPF bandwagon, is the MVP pattern.
In theory all three of these patterns, being patterns, are applicable arcoss any platform. But MVVM was definitely developed with WPF in mind, and as I say Microsoft’s implementation of MVC deviates from the “pure” a little.
There are more, but as I say they’re all broadly aimed at pulling logic out of the UI layer. Martin Fowler’s web site is a decent reference here.