I have an extremely basic Windows Forms app for data capture and reporting on microloans. I have done a pretty good entity model design using EF, but only some initial prototyping with data access via the EF as well as business logic inside Windows Forms methods. I want to now ‘formalise’ the app a bit, and concentrate on writing only UI logic in the forms themselves.
I’m wondering what structures and patterns I can use here? I am used to using a loose repository pattern and view model setup for my MVC3 projects, but haven’t done much winforms work for a few years and am unsure. Some recent reading suggests a repository should purely do CRUD, which would make using one here superfluous and excessive. I don’t want to go as far as a full-on MVVM or MVP design, but I’m stuck wondering where to put what.
The most apparent structure that emerges for me is to extend my entity model to include business logic and operations, e.g. add an AllocatePayment method to the Client class, to allocate a payment made by a client over outstanding loans for the client, and so forth, but this doesn’t smell quite right. Even worse is the looming LoanManager type monolith class, with static methods for everything.
How can I nicely refactor this prototype into a presentably structure app design? I would like to incorporate a TDD approach now, before beginning the refactoring. It seems this will help inspire better low level design of whatever class structures I decide on.
Domain model pattern is quite fine if implemented not as static but as an instance methods. All you objects have its states and some specific behavior.
That’s about where our domain logic should be. In this way unit testing can be written easy. You create an object with some state. Call method and verify if you expectations are met.
Persistence can be done with either ActiveRecord / Repository / DataMapper
I don’t really like ActiveRecord because it violates the single responsibility principle, but it’s my own preference.
There is a great discussion of each particular pattern in Fowler’s EAA and here
To simplify I would go with some sort of already done solution like CastleActiveRecord or implement straightforward Repository.
There is a great post on what repository can look like nowadays
So one option is to make your model containing your business logic. Implement repository / entity responsible for persistence. Forms should only represent your model. And controllers can serve user actions as there is only a finite set of them.
Just in case: data binding is a great feature of WinForms that allows to associate almost any data with controls with zero code.
If there are any restrictions that should be met by your architecture it can be a point of a discussion as each one has its own pros and cons. But MVC pattern is here with us since 80s’ and its audience is only getting wider 🙂