I have a bunch of Domain Objects and I am using overloading to get and set properties.
My form filters are comprehensive. If properties of the wrong type or value sneak through, I am confident that I can pick them up in the mapper. Worst case scenario is that the database throws an exception which I can catch.
In this instance, should I worry about getters and setters in the domain object?
As a best practice, you should always "catch what you can" before you get to the database. Though it may seem as if a round-trip isn't a big deal, they are expensive. Objects have to be created on the server, application pool resources managed, and so much more. Do all the validation you can, though it's tedious, before you get to the database.
The reason you rely on the database to throw exceptions is to ensure its integrity via other forms of access (e.g. import scripts), not to leverage it for your application (which is capable of catching and handling them gracefully).
The final benefit of building the get and set operations is that you can fully encapsulate these bounds checks so that you only have to write the code once, you're going in the right direction!
Well there is no good answer in my opinion for it.
If you do it, you can be 100% sure the value returned is of type x. Otherwise you depend on the data layer for the right stuff.
I check the values, but that is mostly because I like the defensive programming approuch (everything outside the scope is evil and should not be trusted). The domain object is outside the scope of the mapper, so you are not sure what you get.
Next if you make an api of some kind and use the domain objects again out of scope so check the values.
conclusion it depends on the code style you like. So you could implement the getters and settets or just direct to the values.
Although I recommend use at least getters and setters for the case you need to change how values are handeld (array needs to become object for example)
Defining explicit 'getters and setters' will allow you to implement the correct encapsulation for your domain model.
From a setting point of view, this would be type checking for complex values. Then you can perform any validation that is applicable in the context of the domain model.
When the domain model is persisted, this "validation" is really to ensure the values are stored correctly. The only concern the mapper would have is to cast the simple (scalar) values to the correct format (i.e dates etc). These operations tend to be database specific and would probably be better suited within the mapper.
