On 9/23/16 1:39 AM, Dariusz Gafka wrote:
> I meant, that email is just an example. Same problem arrives when we
> have data like "Name", "Surname", which is needed only for reading. For
> example to show it on user's profile.
Yes, I realize it's an example. That's why I was trying to use it for
discussion. (BTW, don't assume that "Name" and "Surname" will never change.)
> Exactly, it works like that :).
> Write Model -> ORM (saves to "users")
> Read Model -> only SQLs (read from "users")
> You got me there, if the schema changes it needs to be changed in two
> places. That's the bottleneck of this solution, but I am aware of that.
> For reading data I don't want to rebuild all domain objects and mess
> with them. It's much simplier and cleaner for Write Model, to operate on
> SQLs directly.
I have always found benefit in putting both read and write in the same
place. This is what Uncle Bob calls the Common Closure Principle
). Otherwise the database
becomes a giant global variable where different clients can interpret
the values and structure differently.
The distance between access of a variable is important. When the access
is within a single method, it's pretty easy to consider them all when
changing one of them. When it's in separate files or modules, it's much
harder. That's why global variables have generally fallen out of favor.
> This is somehow scary, that from unit tests we came to overall
> application architecture.
That's a common occurrence, and one of the big benefits of test driven
development. It's not about testing, but driving the design.
> And leads me to thinking, that there is more things, that I should
> consider that I thought at the beginning.
I recommend always reconsidering past decisions and assumptions. You
should always know more now than you did in the past.
> With current solution I can of course test it using functional tests
> with In Memory implementation. Where scenario contains changing user's
> mail and then sending an email.
> Same about name and surname.
> But this is on higher level and then unit testing "changeEmail()" has
> still no sense.
I'd say that changeEmail() is an incomplete unit. It, coupled with the
code that reads the value, form a unit. A unit test should test that the
value read is the same as the one written. If you've got multiple
clients doing the reading, then you've got multiple units all sharing
the changeEmail() method. Each of them needs testing to make sure they
all change in unison.
> You received this message because you are subscribed to the Google
> Groups "Growing Object-Oriented Software" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to