Best way to handle combined business code and presentation code?

Question

Given the hypothetical situation where the old library of obsolete presentations was maintained over the years, and gradually it introduced more and more business logic into it through a process of hasty corrections and lack of proper architectural supervision. As an alternative, consider a business class or namespace that is not separated from the presentation by the assembly boundaries, and therefore could refer to something like System.Windows.Forms without having to add a link (a much more sobering action than a simple use sentence).

In such situations, it is unimaginable that the business code used by this user interface code will ultimately be called for reuse. What is a good way to rearrange two layers for this?

I am not familiar with design patterns - at least in principle. However, I do not have much practical experience, so I am not sure of my intuitions. I began the journey of using a strategy template for this. The idea is to identify where business logic invokes user interface components to ask the user a question and collect data, and then encapsulate them in a set of interfaces. Each method on this interface will contain UI-oriented code from the original workflow, and then the user interface will implement this interface.

The new code that wants to reuse the business logic in question will also implement this interface, but will replace either new windows, or perhaps preliminary or parameterized answers to questions that were originally answered by the user interface components. Thus, the biz logic can be considered as a real library, although with some inconvenient interface parameter passed to some of its methods.

Is this a decent approach? What is the best way for me to do this? I will give to your collective Internet wisdom.

Thanks!

Answer 1

It looks like you are taking a good approach in which you break the dependencies between specific elements of your design, instead depend on abstractions (interfaces). When you break such dependencies, you should immediately start using unit tests to cover your outdated code base and improve your design with an improved warranty.

I found a book Effectively working with legacy code to be invaluable in these situations. Also, don’t go straight into templates without first looking at the principles of object-oriented design, such as SOLID . They often determine your choice of patterns and decisions about system evolution.

Answer 2

I humbly propose Model-View-Controller - MVC is highly likely as a successful solution to your problem. It shares the different logic as you described.

NTN

Answer 3

I would go to him, clearly defining the essence and actions that they can do or what can be done with them. Then, one after another, they try to create independent business logic objects for those who reorganize the logic from the user interface by making a user interface call for the BL objects.

At this point, if I understood your scenario correctly, you would have a hand full of BL objects, some of which caused calls to win forms, calls to win forms should advance to the user interface level.

Then, as JustBoo says, I think that you will have a difficult enough situation to start abstracting the controllers from your BL and UI and make all this a function in the MVC design.

Answer 4

Well, given your various comments, I would advise Mr. Hoffe and distribute it. I am sure that you have heard that difficult problems must be broken down into ever smaller units of work before they can be "conquered".

Using this technique in combination with refactoring methodologies can solve your problems. There is a book on the Internet and a lot of information about it. You now have a link. This page contains a ton of links to information.

Another link from the author of this book.

So, you are refactoring, slowly but surely, with creamy kindness MVC, step by step.

NTN