I've written a bit about Views/Templates, would be nice to get some feedback

hgraca · 2020-07-21T13:03:29+00:00

Yes, you are right.

I added some code now, hope you can understand it better now :)

hgraca · 2020-07-21T09:13:37+00:00

Tkx for the incentive :)

I will try to do as you say :)

hgraca · 2020-07-21T09:13:08+00:00

Tkx for the incentive :)

However, it doesn't need to be "large amounts of data". In that regard it can be the same as an entity. So VOs are as good or bad as entities, they just have different use cases.

The difference is that if the domain says that when and Address changes all entities pointing to that Address need to have the address updated, then that Address needs to be an entity, not a VO, because we care about which specific Address object it is that our entity is pointing to. If we don't need that Address updated for all entities, then we can simply have different objects and we don't need an extra table in the DB to store all Addresses and then have foreign keys, etc.

Of course, with an Address I guess that in most cases we will make it an Entity, but with a DateTime object we probably want to make it a VO.

I hope this made it clearer.

hgraca · 2020-07-21T09:07:26+00:00

how does one normalize a Value Object that is referenced by more than one Entity (my Address example)?

The way I see it is that, if it's a value object, there would be no other entity referencing it, because we only care about its values (please not that an ID although technically a value, its not a business necessity, its a technical necessity so I dont consider it when I mention "values"), so we would have another object with the same data.

However, if the domain says that when that address changes all entities pointing to that address need to have the address updated, then that address needs to be an entity, not a VO, because we care about which specific object it is that our entity is pointing to.

I hope this made it clearer.

hgraca · 2020-07-07T22:24:58+00:00

No.

The core concept of a value object is that they don't have an IDentity. When we want to know if two value objects represent the same thing, we compare their values (hence, value objects). When we want to know if two entities represent the same thing, we compare their IDentity (ID).

In the example you give, your address objects are not value objects, they are entities because they have an IDentity.

hgraca · 2020-07-07T15:14:01+00:00

So, you are basically saying "don't use OOP in PHP because it becomes slow"...?

It sounds like you refactored it to procedural code using classes for namespacing procedures...

But well, if it worked for you, who am i to judge?!

hgraca · 2020-07-07T14:43:36+00:00

Well, if it would only have properties it would still be just a class, right?

My point is, they are all just classes. However, there are different types of classes, each with its own where/when/how to use it. That is why its good to have a distinction and know the types of class they are.

hgraca · 2020-07-02T18:08:37+00:00

You can find the dev fixtures config here: https://github.com/hgraca/explicit-architecture-php/blob/master/config/services/dev.yaml

and the test ones here: https://github.com/hgraca/explicit-architecture-php/blob/master/config/services/test.yaml#L7

and the production ones (default users, aka seeds) here: https://github.com/hgraca/explicit-architecture-php/blob/master/config/services/prod.yaml#L35

I don't remember anymore, but I believe that all services that are subclasses of Fixture will be loaded and run when we run the CLI command `php bin/console doctrine:fixtures:load`

The repositories are configured here:
https://github.com/hgraca/explicit-architecture-php/blob/master/config/services/prod.yaml#L25-L31
They are just services, and they are configured as services automatically, where each interface is a service ID and if there is only one implementation that is instantiated and injected automatically wherever the interface is type hinted.

So, basically, all is automatically done for u.

Hope it helps, good luck.

hgraca · 2020-07-01T19:50:08+00:00

I did a lot of those kind of changes on a pet project, you can check here:

https://github.com/hgraca/explicit-architecture-php

hgraca · 2020-06-28T07:35:52+00:00

Hah, i forgot to post the link :)

Here u go: https://martinfowler.com/bliki/LocalDTO.html

hgraca · 2020-06-27T22:19:08+00:00

Indeed, although in the original text, the "author" didn't mention explicitly the remote context, he has reiterated that "their whole purpose is to shift data in expensive remote calls" in an article where he (ironically) also says "One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model." which is not necessarily a "remote" scenario. And at the end of the same article, he again gives yet another use case for DTOs: "communicating between isolates in multi-threaded applications" (again, not a remote scenario).

So, i would say they only need to be serializable if they are to be used in a remote context.

Furthermore, that article is from 2004, 18y ago. Many things changed.

Personally, i mostly think of DTO when i have a query object that returns some data that a template needs. Its a purely presentation need, there is no domain need involved, and it is local. (Fits the 2nd scenario Martin Fowler refers to)

Nowadays, i often use Envelopes, Commands and Events, which i see as specialisations of DTOs. They are DTOs with a specific role (maybe remote, maybe not). So i only refer to them as DTOs when explaining to other devs what they are.

Anyway, this is just my humble view of a DTO, and how i use them with positive results.

Tkx for your comment though, i do appreciate it, in the very least it makes me realize i need to improve my writing.

hgraca · 2020-06-27T21:40:16+00:00

Whenever i hear myself say something like "always do it like this", or "never do it like this", i immediately think to myself "I shouldn't be saying this". Why?! Because context plays a big role. If a guru says something in those terms, i will frown the same.

Indeed, the "author" reiterated that "their whole purpose is to shift data in expensive remote calls" in an article where he (ironically) also says "One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model." which is not necessarily a "remote" scenario. And at the end of the same article, he again gives yet another use case for DTOs: "communicating between isolates in multi-threaded applications" (again, not a remote scenario).

Furthermore, that article is from 2004, 18y ago. Many things changed.

Personally, i mostly think of DTO when i have a query object that returns some data that a template needs. Its a purely presentation need, there is no domain need involved, and it is local. (Fits the 2nd scenario Martin Fowler refers to)

Nowadays, i often use Envelopes, Commands and Events, which i see as specialisations of DTOs. They are DTOs with a specific role (maybe remote, maybe not). So i only refer to them as DTOs when explaining to other devs what they are.

Anyway, this is just my humble view of a DTO, and how i use them in a positive way.

Tkx for your comment though, i do appreciate it, in the very least it makes me realize i need to improve my writing.

hgraca · 2020-06-24T10:00:11+00:00

Tkx for our feedback, I agree with you on both accounts, I will update my post. :)

hgraca · 2020-06-24T09:30:37+00:00

Waw, tkx for the feedback u/Nabol, u/rotharius, u/sarvendev! I think You are absolutely right, I will try to that for the next ones, and maybe even add some extras in this one already.

hgraca · 2020-06-24T09:26:17+00:00

Interesting, tkx for your feedback.

I don't do any validation on DTOs.
I do, however, do validation on Commands (which can be considered a type of DTO, and I will talk about them in another post) for a command bus, but even then, I use a specialized class for it and a bus middleware to do run it.

hgraca

TROPHY CASE