Home/ Questions/Q 96095

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T23:45:40+00:00

This question is language agnostic but I am a C# guy so I use

  • 0

This question is language agnostic but I am a C# guy so I use the term POCO to mean an object that only preforms data storage, usually using getter and setter fields.

I just reworked my Domain Model to be super-duper POCO and am left with a couple of concerns regarding how to ensure that the property values make sense witin the domain.

For example, the EndDate of a Service should not exceed the EndDate of the Contract that Service is under. However, it seems like a violation of SOLID to put the check into the Service.EndDate setter, not to mention that as the number of validations that need to be done grows my POCO classes will become cluttered.

I have some solutions (will post in answers), but they have their disadvantages and am wondering what are some favorite approaches to solving this dilemma?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. I think you’re starting off with a bad assumption, ie, that you should have objects that do nothing but store data, and have no methods but accessors. The whole point of having objects is to encapsulate data and behaviors. If you have a thing that’s just, basically, a struct, what behaviors are you encapsulating?

    • 0