Business logic plus data, or separate the two? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

My understanding is that the fundamental tenant of OO design is that one should focus on modeling a class as the union of code and data. In day to day development, however, I tend to separate all of my business logic into classes of their own. The 'data' ends up being in tightly controlled POCOs/DTOs with basically no real code or logic. I then instantiate a business logic class and pass in POCOs to each method whenever I want an operation to occur.

But this feels like two separate approaches. In fact, the latter approach seems to be at odds with the purpose of OO!

I supposed I've always kept the two things separate since business logic may function on multiple POCOs. Plus, not forcing validation on the data in the POCOs made it easier to unit test since it seemed simpler to prepare the POCO for a test (no need to worry about internal class state, encapsulation, etc). Now that I'm looking back on those reasons, they seem weak.

I'm looking for a comparison/contrast of the two approaches. Specifically, why does it seem that making 'dumb' POCOs is the way to go these days? Why not just stick the data and the business logic into a single class? Are we abandoning the original goals of object oriented design?

Thanks!

Answer 1

Indeed, separating business logic from associated data goes against the principles of OOP, and this is what Martin Fowler refers to as an anemic domain model. Personally, I would always go with a proper domain model that puts data and behaviour together.

Specifically, why does it seem that making 'dumb' POCOs is the way to go these days?

I don't know why you thought this was so, but this is certainly not true. There are many "dumb" models out there, but there are also many well-designed domain models.