I have legacy win.forms application written in pretty straightforward approach where forms communicate with DAL on UI events. For example there are textboxes: login/password, button - "Login" and a click-handler where business logic is implemented (DAL is asked to get user by id/password, if not null - than show next screen, if null - show "retry screen").
I have no ability to rewrite it from scratch (in MVP or View/Document pattern), I just want to separate business logic from handlers: grab existing handlers code that communicate with DAL and group it somewhere out of UI handlers.
Dozens of forms are composed with dozens user controls and it's often not clear who is responsible for business logic. Sometimes it's UI control. But sometimes it's a form, who is listening for custom UI-control event and then implement business logic.
If I separate business logic, who should be responsible to call business logic controllers? Forms, user controls, or forms and user controls simultaneously?
Thank you in advance!
My subjective opinion would be to decouple as much as you can. Stick all the business object code in a library or class of its own, place all the behavior relating to your business objects that you can into that class. Then allow your UI code to call in. If you need to wait between the communication (such as searching a huge database for log in credentials), halt the UI until it hears a response from your business objects. The advantages of this approach is that you could theoretically distribute it in the future.. having the server running the back-end code and the UI simply sending requests and awaiting responses. Though perhaps I misunderstood your question?