When you have an object model, you tend to use whatever types are most appropriate for the in-memory execution model, e.g., boolean. When you have a database, you use data types that are native to that particular database. In some (most?) cases, those will differ. Whose job is it to map between those representations? I hoped it would be obvious that the data layer (DAOs and gateways) 'own' that transformation but it appears to need re-stating:
It is the job of the data layer to perform the necessary mappings between the persisted database schema types and the in-memory object data types.
So a boolean in an object might be mapped to / from a varchar(1) 'Y' or 'N' value - in the DAO.
What about validation? Well, the DAO doesn't (shouldn't!) know anything about your business logic beyond knowing what in-memory data types you use. It might know a date of birth field is mapped to / from a datetime or date column but it doesn't care about valid date ranges or any such business stuff. Validation belongs somewhere in the business layer.
Now, whether you have smart beans with their own validation or dumb beans with external validation is up to you. The point here is that the business logic 'owns' the task of applying that validation to the bean before using the bean in additional business logic (and, therefore, before passing the bean to the data layer for persistence).
Here's an interesting use case tho': your application wants to store unvalidated data (because an object can be in many states, perhaps, and you're following a principle of enterprise robustness of persisting all the data you receive for audit purposes). By definition, this means your persistence model must support untyped (i.e., string) data. That also means your DAO must do no transformation. And that in turn means that it is the job of the business layer to decide whether the data is 'valid enough' to operate on. All the same, the business layer still owns validation (although it's now optional), the data layer still owns transformation (although it's now an identity operation).
The layers and responsibility are always the same. The details may change.
I mentioned it out loud more to state openly that a from my reading online and watching folks use it inside code, the "assumption" factor does get overlooked.
I also stated that I'm not against them, but find that without frameworks such as the ones i mentioned, their use can get diluted and abused in terms of transfer vs validation.
It also raises a point of how DAO's can take on more "dependencies" then a simple standalone object, in that transforming common data between two points A to B, can get to become a code headache if every CRUD routine (or if you prefer to combine DG into DAO) has its own piece of logic. So a way out is maybe inject an object into the DAO on construct, or at runtime "mix-in" a function or two.. overall DAO's need to be treated with a bit more planning then from what i've seen overall thus far online.
Stuff like contructs of a DAO that soley rely on DSN information to me? absolutely baffles me as to how that could be considered legitimate? ColdSpring and Tartan allow for these types of arguments to be specific to the context of the application (which is fantastic) - yet - standalone its been happening.
Hey i'm not a guy with all the answers, i just present information online, throw an opinion or two and see what sticks?
Bashing... i'm not that aggressive ;)
