Business logic invading UI in a large winforms app

Question

I have seen this theme present itself more than once now. I am hoping that people here who are currently in similar situations or have been in the past can offer some insightful advice. It might be useful if you share your past experiences as well.

So there is this fairly large windows forms application that has been developed over the years. Though the development team has tried to separate business logic from the UI, it hasn’t quite happened and there are numerous areas of the code where the business logic is hard-wired to the UI. In fact remnants of previous attempts to adopt MVP architecture can be seen at a lot of places. There are unit-tests too but with a relatively low degree of code coverage. There are some hot spots however – areas which everyone knows have gotten more complicated that they necessarily need to be.

A lot of times bugs which could have possibly been caught earlier are only found once Testers grab their torch lights and really start looking for bugs which is unfortunately too late, expensive, and risky. Engineering, testers and PMs - all realize that something needs to be done.

What would be the most practical way to address the situation altogether, or improve the situation? Since it is going to be a long task, what would be the best way to measure the progress towards the goal? How would the goal be defined in objective terms to begin with?

Answer 1

You need to rearchitect the Business Layer and then wire the UI back into this rearchitectured layer.
You keep the existing UI and hardwired business logic going while this is done and switch it over to the new ones one form at a time.

This has the benfits of allowiing you to add all the unit tests and automated testing tools you need while the effects are small. You can also make sure that your components are doing what they need to do properly.

Basically, it is a long haul with limited Return on Investment in the short term but with potential big benefits in the medium to long (really just long) term.

Answer 2

How profitable is the product? How large is the team?

These questions will be your starting point for a solution. The more profitable and larger the team the faster you will be able to refactor code to a newer form.

But with large projects there is typically a lot at risk with changes to the code. There must be areas that "just work" that haven't been looked at in years. Getting bugs in these areas will be a big challenge. It will take awhile to get your gears spinning to even debug these areas.

My though is to study the code in detail. When you are really sure you know it cold, give a presentation to others that are knowledgable in the code base. This will point out the next batch of code that you thought you knew but didn't. As the code starts to get into your head a clearer and clearer picture of what is needed will just emerge in your mind. Then you are ready to work out a plan for the first step. Make it something reasonable and don't bite off too much.

Above all, learn and have fun. Re-working a large project can be quite fun as long as you have the right attitude.

Answer 3

"Business logic invading the UI"... I love the word choice.

• First and foremost, get code coverage up with unit tests.
• After that, review Martin Fowler's Refactoring book.
• Apply a long series of Extract Class refactorings to form a domain layer. After each one, re-run your unit tests to make sure you have green bars.
• Once you're happy with the new code, delete the old stuff.
• Eventually, you'll want to Introduce Controller.

Of course, a tricky part will be unit testing the UI. You might have to first Extract Method in the UI itself in order to unit test the bits of logic floating around in there, and then follow the steps above.

Answer 4

Sounds like you have quite a challenge ahead of you!

In the broadest terms, I think you have to start by working with your team to very clearly define exactly what you consider to be acceptable and what is unacceptable.

In my experience, a certain degree of business logic (such as validation) has to be in the UI (although it should also be enforced in the business layer, too).

Once you have a clear definition of what's acceptable and what isn't, it should be a relatively mechanical (although daunting) task to list out the violations in the project.

That will give you a clear indication of the scale of the problem - and is really the only place you can sensibly start from if you intend to solve it in any measurable way.