> Nino Martincevic wrote:
>> Therefore:
>> Why not use "logical type", like Birthdate, Address, even Username?
>> If you create a logical object for every one of it you can handle
>> all semantic validation and even formatting in one place.
>>
>> So, instead of having to check a date in every model that uses a date
>> you would have to create a Date object and send it to the model, or any
>> other component of your software, if it is validated.
>
> This is not semantic. This date or username doesn't have a meaning yet.
> You can validate username sting format or if the username exists in the
> databaase but it's still meaningless. It's a generic validator which can
> be used on all application objects.
Well, perhaps that wasn't explained accurate.
I wasn't talking about semantic in first place but of logical data
objects as types. Instead of having to check a birthdate in several
places (or different models) or in several ways there is one and only
one Birthdate object you work with, never mind where.
It *has* a meaning then in my domain model, it is not a simple date
object. But of course you could also use simpler types (like phone
number, address, zipcode).
So if you need a birthdate somewhere you create a new object and provide
all necessary attributes for creating it. It checks for itself if it's
valid, either syntactic and/or semantic. A semantical check would be
e.g. if the date is in the future, like you said before. Birthdate cant'
be in the future so the creating would fail in that case.
Only if all checks are passed and the creation succeded you get a valid
Birthdate object back and may use its behavior and data. Depending on
the type it can have additional behavior and info retrievals like a
static isValid() function for pre-checking (used internally at
construction time), dayPart(), ageToday() or whatever.
So you always work with that logical (and conceptional) data types,
never with generic ones like numbers, string, dates etc.
Calling and passing these types around always ensures that they are
valid and you don't need to check it in layers below.
> Further, if you write all your validators as separate service objects,
> no matter how specialized they are, you will probably end up with anemic
> data model:
> http://www.martinfowler.com/bliki/AnemicDomainModel.html
The focus here is not on validators but on conceptually valid and
"complete" objects with a meaning to a domain.
I think you mix up different things there. Anemic means in first part
objects with no behavior, just data containers with no responsibility
but transfer data.
And one of the most important principles is SRP, so a birthdate object
that handles all about creating, maintaining and retreiving itself
follows this principle (and DRY of course).
Any model that retrieves, validates and saves data is god-class like
because the responsibilites are by far to many, no SRP in sight.
And indeed they are all but anemic because they even have behavior,
responsibilty and, most important, a meaning.
没有评论:
发表评论