oo question - mixing controller logic and business logic

Question

I'm not sure if I'm using "standard" terms, but this is a basic OO question I'm trying to resolve.

I'm coding a windows form. I don't want logic in the form event handler, so I just make a call to a custom object from there.

At the custom object, there are two sets of logic.

1. The "controller" logic, which decides what needs to get done and when.
2. The actual business logic that does what needs to be done (for example a control that performs a math operation and returns results, etc.).

My question is, does OO architecture allow for having both of these in a single object? Or is it recommended to split them out into a "controller" object and a "business logic" object? Is there a design pattern I should refer to for this?

For the time being, I've started down the route of combining them into one object. This object has a "start" method which contains the controller logic. This method then calls other methods of the object as needed, and ultimately returns results to the caller of the object.

Answer 1

No, I don't put business logic in controllers. I add an intermediate service layer that's injected into controllers. Let the service do the work. Controllers are for routing requests and marshaling responses.

Putting the logic in a clean service layer is "service oriented", even if you aren't using web services or WSDL. It has the added benefit of still working if you decide to change controller/view technologies.

Answer 2

What you're doing is a form of "fat controller" architecture. These days software development is trending toward thin controllers.

OO design is all about decoupling. If you internalize only one thing about OO programming, let it be that.

Check out "Domain-Driven Design Quickly." This free e-book is a condensed introduction to the concepts covered in Eric Evans' important book "Domain-Driven Design."

Getting educated in these concepts should help you to understand how to separate business logic from the controller, or service layer.

Answer 3

In general, you should probably have these in two different objects, but there's a qualifier on that. It may make sense, if your project is small enough and your object model is not complex enough, to have the functionality composed into one object; however, if your functionality is complex enough, it's almost certainly going to be better for you to segregate the controller and the business objects. At the very least, design the system with an eye towards separating the controller and the business objects at a later point, if you don't completely separate them now.

Answer 4

The answer to you design question can is as the following scenario: how would you design your application if you also had to provide a web-client for it.

Both your Windows Forms UI and you Web UI would be calling the same classes and methods. The only difference, then, would be how each populates the UI and communicates with the other layers.