Making legacy straightforward win.forms application code more clear

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 co开发者_开发问答de 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!

As with most refactoring, take small steps.

Start by extracting the code to a new method. So instead of all the login code in the btnLogin_Click event, you would simply have a method called LogUserIn() or something along those lines.

Once you've done this for some (or all) of the event handlers you'll likely start seeing some common trends. Perhaps there is a log out that is relatively similar. Now you've got two methods for a new class.

You can then start using that class in your event handlers. Something like UserData.Login(name, pw) and UserData.Logout(name)

Don't try to do everything at once. Make a change, verify it works, make another change, verify it works ad nauseam.

Remember, you don't have to make the perfect refactoring right out of the gate, even an incremental change sounds like it would be a drastic improvement.

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?