Documentation about getters/setters to DTOs and Value Objects #6902

Pierstoval · 2017-12-18T19:42:04Z

I recently tweeted about this, but the original questioning comes from @javiereguiluz:

The "Getting started" guide refers to getters and setters as the base of an entity's behavior, but the Doctrine core team and other experts certainly prefer mapping rich accessors and mutators. @Ocramius also gives this advice in his "Doctrine beset practices" conference (slides here).

This PR is not a final proposal, but more a starter about a change to the documentation to suggest using a rich model for our domain instead of relying only on getters and setters.

I thought it would still be nice to bring the getters and setters and then talk about DTOs and rich model, to keep consistency with the 95% (arbitrary number) entities created by developers these days, especially the ones using Symfony (and mostly because the Symfony Form component uses getters and setters a lot, and most docs propose to inject them in our forms rather than relying on a DTO).

WDYT about this?

Majkl578 · 2017-12-18T22:51:49Z

edit: This was a reply to a comment that has been deleted, it suggested to use constructor to set value and keep entity immutable only with a getter.

Agreed on constructor + immutable state being easier to understand in Getting Started. But behavioral methods should be explained too at some later point. For example, changePassword($newPassword) would be good example.

Referencing symfony/symfony-docs#8893 - similar issue for Symfony docs.

fesor · 2017-12-18T23:18:34Z

I don't think that information about proper modelling fits to "getting started" section... This is far more complicated topic. You could change examples, like remove setters:

<?php
// src/Product.php
class Product
{
    /**
     * @var int
     */
    private $id;
    /**
     * @var string
     */
    private $name;

    public function __construct($name)
    {
        $this->name = $name;
    }

    public function getId()
    {
        return $this->id;
    }

    public function getName()
    {
        return $this->name;
    }
}

and

$product->rename($name);
// instead of
$product->setName($name);

Doctrine doesn't enforce users to use setters, so i don't think why it used in documentation. But with getters there are different story. Since #6719 will not be available to users until 3.0, it will be just to complicated to describe why you still need getId() getter so you could fetch ID of related entity for example without actually preform db query.

Anyway, right now documentation contains something like:

When creating entity classes, all of the fields should be protected or private (not public), with getter and setter methods for each one (except $id).

this literally enforce users to use getters in setters in their models. And the only reason for that is how doctrine use accessors for lazy load. Probably it will be better to replace mutators to accessors.

Also I think that it would be useful to describe concepts of persistence ignorance instead of digging into DTO/UoW stuff in the getting started section. For example some of the devs thinks that Doctrine is calling constructor of entities for each fetch, and many problems comes from the fact that they don't understand that entities this simple concepts.

You could provide links on separate sections which will provide more detailed information. Like "how to use entities with forms" and so on. Something for cookbook rather than "getting started".

Ocramius · 2017-12-19T23:25:41Z

The requirement for accessors is no longer needed since Doctrine ORM 2.3, where we added full support for public properties. In 3.x we will even support friend objects.

…

On 19 Dec 2017 00:18, "Sergey Protko" ***@***.***> wrote: I don't think that information about proper modelling fits to "getting started" section... This is far more complicated topic. You could change examples, like remove setters: <?php // src/Product.php class Product { /** * @var int */ private $id; /** * @var string */ private $name; public function __construct($name) { $this->name = $name; } public function getId() { return $this->id; } public function getName() { return $this->name; } } and $product->rename($name); // instead of $product->setName($name); Doctrine doesn't enforce users to use setters. But with getters there are different story. Since #6719 <#6719> will not be available to users until 3.0 will be released, it will be just to complicated to describe why you still need getId() getter so you could fetch ID of related entity for example without actually preform db query. Anyway, right now documentation contains something like: When creating entity classes, all of the fields should be protected or private (not public), with getter and setter methods for each one (except $id). this literally enforce users to use getters in setters in their models. And the only reason for that is how doctrine use accessors for lazy load. Also I think that it would be useful to describe concepts of persistence ignorance instead of digging into DTO/UoW stuff in the getting started section. You could provide links on separate sections which will provide more detailed information. Like "how to use entities with forms" and so on. Something for cookbook rather than "getting started". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6902 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakB6bL2XF2GNf7pywjIxUJmH-wMdiks5tBvLMgaJpZM4RF-MX> .

fesor · 2017-12-20T09:53:11Z

docs/en/tutorials/getting-started.rst

+For example, when having a ``User`` entity, we could foresee
+the following kind of optimization.
+
+Before, an anemic model with getters and setters:


there are sections "Getting Started: Database First" and "Getting Started: Model First". I think this sections could cover "anemic vs rich model" cases.

I think it's a.... rich idea 😎

fesor · 2017-12-20T09:53:55Z

docs/en/tutorials/getting-started.rst

+
+            public function authenticate(string $password, callable $checkHash) : bool
+            {
+                return $checkHash($password, $this->passwordHash) && ! $this->hasActiveBans();


what about cases with password_needs_rehash?

It's an example retrieved from Marco's talk about doctrine best practices, but of course it can be changed :)

@fesor I think this is a good example of how a rich domain model aids in better maintainability later on. Not sure if it would fit a simplified example though. Maybe just skip it for now?

Yes, probably this something that could be covered later in some cookbook (like how to deal with dependencies).

Hi guys.
I appreciate the effort you put in updating the documentation and promote better programming practices.
I agree with @fesor that the "dealing with dependencies" topic must be covered. Yes, it can be in some cookbook, but it must be covered because it will be an issue people will run into very quickly and not finding anything related to this will probably make them to give up and go to the well known "don't put behavior in your entities, just put data and make some services that will operate on your entities through some setters".

Majkl578 · 2017-12-23T01:12:30Z

docs/en/tutorials/getting-started.rst

+                return $this->username;
+            }
+
+            public function setUsername(string $username) {


👍 for types, also add void

Majkl578 · 2017-12-23T01:14:10Z

docs/en/tutorials/getting-started.rst

+                $this->passwordHash = $hash($password);
+            }
+
+            public function ban()


It may be interesting to see some parameters here. I.e. \DateInterval $duration + assert() that it's non-negative. WDYT?

ostrolucky · 2017-12-30T20:15:02Z

Some pretty big words unnecessarily used here for getting started guide. I suggest following changes (I focused on getter/setters option, not sure how to change the rest)

 Adding the Entity behaviors
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You have two options to define the accessors mutators that will
-update the state of your objects.
+You have two options how to define methods in your entity.
 
 **Getters and setters**
 
-The most popular method is to create getter and setter methods
-for each property (except ``$id``). The use of mutators allows
-Doctrine to hook into calls which manipulate the entities in ways
-that it could not if you just directly set the values with ``entity#field = foo;``.
+The most popular option is creating 2 separate methods for reading
+(getter) and updating (setter) for each field in your entity.
+Some fields, such as ``$id`` are undesirable to be modified and as
+such it's ok to not provide setters for them.
 
-The id field has no setter since, generally speaking, your code
-should not set this value since it represents a database id value.
-(Note that Doctrine itself can still set the value using the
-Reflection API instead of a defined setter function)
+This is a convention which makes it possible to expose each field
+in your entity to external objects in automated way, while allowing
+you to keep type safety in place.
+
+Such approach is good choice for RAD (rapid application development),
+but may prove problematic later down the road, because providing such
+easy way to modify any field in your entity means entity itself cannot
+ensure it's in valid state. Having entity in invalid state is dangerous,
+because it's one step away from being implicitly saved in database.
 
 .. note::
 
-    This method, although very common, is **not** the best approach if
-    you want a perfect domain design. It can lead to unexpected behavior
-    when dealing with different steps of logic in between different
-    calls to ``EntityManager::flush()``, for example when you change
-    the state of an object via event listeners or lifecycle callbacks.
+    This method, although very common, is inappropriate for domain driven
+    design, because in such design, methods should be named according to
+    actual business operation and entity should be valid at all times.
 
 **Mutators and DTOs**

fesor · 2018-01-02T11:58:51Z

I thought about this a little bit (and asked some of the developers in local community about pit-fails in learning doctrine).

The goal of "getting started" section of every tool is to have it running it as soon as possible (within 10-15 minutes). This is very important to not scare new developers with complexity of the tool. So there should be bare minimal information with only hints about preferred way of designing entities (like remove setters from samples). Al other things should be covered in other sections.

From what I know, getters/setters are mostly used since getting started guides of other tools (like forms, CRUD generators and so on) are provided this examples as most straightforward way to start. later in documentation most of this tools covers how to handle DTO, value objects and other stuff, but in format of cook books. However most of the tools doesn't cover this information (api-platform for example, or sonata admin bundle) which make it hard to developers to start without at-least setters.

So if Doctrine's documentation will push to one direction, and other tools like forms components in to another, and there will be no handy tutorial on how to mix concepts, developers will fall into cognitive dissonance.

Another thought. I faced with fact that most of the developers just don't know how to handle updates in CRUD based application. Basically they need to replace most of the entity data in update operation, with some kind of control. I teach my team to rely in immutable data since in this way we could replace "update" to another "create" operation but in different context. This requires understanding of concepts like value objects, which represented in Doctrine as Embeddable. Unfortunately "Separating Concerns using Embeddables" section is just not contain enough information and many developer event don't know about embeddable available to them.

I think that embeddable should be covered right after entities in basics of the ORM. Also I found structure of documentation not user friendly. Use of embeddables are simplifies understanding of how to better structure business logic into separate objects.

Another "pattern" in behaviour which I found, is how data modeling is happening. For example in some application we have users. And we also have some kind of referral program. And also users could be both merchants and customers. And each has profiles. Most of the devs which I talked with putted all this logic in same User entity eventually will break SRP and will be too big to maintain. And having multiple entities which are referencing same ID and used in different contexts is counterintuitive to people which doesn't want to know anything about DDD and other fancy stuff.

This probably something that should be at lest slightly covered in "Getting Started: Model First". Or maybe instead of two sections there should be one - "Getting Started: Entity Design Approaches" which will have high-level description of different approaches with list of pros/cons of each.

Also I think that restructuring welcome page will have much more benefits to simplify learning projects. Documentation structure should provide much more cleaners way of learning Doctrine.

Pierstoval · 2018-01-02T13:15:44Z

I'm not sure we should document Embeddables right after the "Getting started" guide. It is related only to specific needs which are not very common, as most of the times, having entities and relations is a better option, could it be for the DBMS or for your domain.

For the rest, I take all your comments in account and will make updates on this subject in the next days/weeks.

In the meantime, thanks everyone for participating in this very interesting discussion, happy new year, and may 2018 give you more free time for OSS 😄 🎉

fesor · 2018-01-02T14:48:33Z

right after the "Getting started" guide

not right after "getting started". But at least in "Mapping Objects onto a Database"

It is related only to specific needs which are not very common

mostly since many developers even don't know about it. That's why I think it would be better to start from restructuring links on welcome page instead of rewriting getting started. The only thing is to remove obsolete information like "all properties should be protected (private)".

lcobucci · 2018-01-15T10:22:40Z

docs/en/tutorials/getting-started.rst

@@ -103,7 +103,7 @@ Install Doctrine using the Composer Dependency Management tool, by calling:
    $ composer install

 This will install the packages Doctrine Common, Doctrine DBAL, Doctrine ORM,
-Symfony YAML and Symfony Console into the `vendor` directory. The Symfony 
+Symfony YAML and Symfony Console into the `vendor` directory. The Symfony


Maybe we should remove Symfony YAML from this page? I mean v3 already removed support for it, v2.7 deprecates it, and I think we should start phasing it out ASAP.

Can you please also update the version in L90?

Yes, I will, I'm just waiting for a moment when I'll have more time for this PR, it's hard work 😉

marek-pietrzak-tg · 2018-01-15T13:29:57Z

docs/en/tutorials/getting-started.rst

        }

-        public function setName($name)
+Additionnally, our entities should never see their state change


Additionnally -> Additionally

marek-pietrzak-tg · 2018-01-15T13:32:16Z

docs/en/tutorials/getting-started.rst

+Entities should represent **behavior**, not **data**, therefore
+they should be valid even after a ``__construct()``.
+
+To help creating such objects, we can rely on ``DTO``s, and/or make


make our entities Value Objects.
Can we rephrase it? From DDD point of view VOs and entities are different concepts.

greg0ire · 2018-01-19T22:51:43Z

docs/en/tutorials/getting-started.rst

+    .. code-block:: php
+
+        <?php
+        class User {


This is not PSR compliant, neither is the code below

greg0ire · 2018-01-19T22:53:48Z

docs/en/tutorials/getting-started.rst

+* DTOs can be reused in other components, like when deserializing
+mixed content, using forms...
+* Anemic model tends to isolate the entity from the logic, and a
+rich model fixes that because entity's logic can be put in the


"the entity's logic" I think

Pierstoval · 2018-03-16T22:21:50Z

Fixed all your review @greg0ire, but next time, could you add them in a Github review so we can hide them when fixed? 😅

Pierstoval · 2018-03-16T22:30:56Z

By the way, for reviewers, I just made some changes to the text, if you could review again 😉

greg0ire · 2018-03-17T06:58:07Z

@Pierstoval that's what you get for mentioning me in a commit message :P. You can still squash if you want them to disappear though

Ocramius · 2018-03-17T09:16:11Z

docs/en/tutorials/getting-started.rst


-        public function getId()
+When creating entity classes, all of the fields should be protected or private (not public).


We should probably rephrase to something like:

should be private, protected when strictly needed and very rarely if not ever public

I can also add that protected and public have some performance overhead (minimal, but it is there). Unsure if we can pack it into the article.

I don't think that we need to introduce any limitations in getting started at all. Only one that are really limitations of Doctrine. Proper entity modeling could be covered elsewhere.

I'm not sure the performance overhead might be interesting for end-users to know.

@fesor it's not a limitation (of Doctrine) is it? Just a good recommendation. There's no explanation though, and the performance concerns are additional to something else.

How about

When creating entity classes, fields should be private, protected when strictly needed and very rarely if not ever public, to make sure encapsulation is not broken by needless exposition.

Ocramius · 2018-03-17T09:16:42Z

docs/en/tutorials/getting-started.rst

-        public function getId()
+When creating entity classes, all of the fields should be protected or private (not public).
+
+Adding the Entity behaviors


Adding behavior to Entities?

Ocramius · 2018-03-17T09:17:45Z

docs/en/tutorials/getting-started.rst

+Adding the Entity behaviors
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You have two options to define to define methods in your entity:


It is a good idea to keep things very impersonal.

There are two options and in entities

Also, to define is used twice here

Ocramius · 2018-03-17T09:19:51Z

docs/en/tutorials/getting-started.rst

+The most popular method is to create two kinds of methods to
+**read** (getter) and **update** (setter) the object's properties.
+
+Some fields such as ``$id`` are unlikely to be changed, so it's ok to


overall, try not abbreviating it's - keep it is

Ocramius · 2018-03-17T09:21:24Z

docs/en/tutorials/getting-started.rst

+
+.. note::
+
+    Setters are unrelated to Doctrine itself, because the ORM does not


It is true that they are unrelated, but that's not how it should be explained to the reader.

I think a better approach is to say something like:

Doctrine ORM does not use any of the methods you defined: it uses reflection to read and write values to your objects, and will never call methods, not even __construct

Ocramius · 2018-03-17T09:44:46Z

docs/en/tutorials/getting-started.rst

-Reflection API instead of a defined setter function)
+There are several advantages to using such model:
+
+* Entity **state is always valid**. No setters means that we only


highlight Entity as part of the bold section

s/No setters means that/Since no setters exist,

Ocramius · 2018-03-17T09:45:37Z

docs/en/tutorials/getting-started.rst

+* Entity **state is always valid**. No setters means that we only
+update portions of the entity that should already be valid.
+* Instead of having plain getters and setters, our entity now has
+**real behaviors**, meaning it is much easier to determine the


s/behaviors/behavior

Also: you really like the word "meaning" :D

Can be simplified: **real behaviors**: it

Yeah, I need to improve my english language a bit 🤣

Ocramius · 2018-03-17T09:47:08Z

docs/en/tutorials/getting-started.rst

+* Instead of having plain getters and setters, our entity now has
+**real behaviors**, meaning it is much easier to determine the
+logic in the domain.
+* DTOs can be reused in other components, like when deserializing


s/like when/for example

Ocramius · 2018-03-17T09:47:24Z

docs/en/tutorials/getting-started.rst

+* DTOs can be reused in other components, like when deserializing
+mixed content, using forms...
+* Classic and static constructors can be used to manage different
+ways to create our objects, and they can also use DTOs.


s/use/rely on

Ocramius · 2018-03-17T09:48:31Z

docs/en/tutorials/getting-started.rst

+* Classic and static constructors can be used to manage different
+ways to create our objects, and they can also use DTOs.
+* Anemic models tend to isolate the entity from logic, whereas
+rich models fix that because logic related to the entity can be


fix that because

"fix that" is strange to read in this context, because it is not immediately obvious that this is a problem. We only briefly explained that anemic models lead to some issues, but we didn't explain that logic outside entities versus inside is worse.

greg0ire · 2018-03-17T21:54:47Z

@Pierstoval I have access to a computer again and deleted my comments to keep this PR relatively clean

greg0ire · 2018-03-18T10:36:22Z

docs/en/tutorials/getting-started.rst

+**Anemic models: Getters and setters**
+
+The most popular method is to create two kinds of methods to
+**read** (getter) and **update** (setter) the object's properties.


"read" and "update" sounds weird, how about:

"read" and "write"?

"share" and "mutate"?

I thought read & update were nicer. By adding "write", I'm confused with the fact that we read something but we write in something, and I didn't want to bother with my imperfect english 😆

"share" and "mutate" are closer to the DDD & rich entities approach, and these are words that are possibly unknown by many developers, so I didn't want to add them in the common anemic design

greg0ire · 2018-03-18T10:41:43Z

docs/en/tutorials/getting-started.rst

+of your entity to external services, while allowing you to keep type
+safety in place.
+
+Such approach is a good choice for RAD (rapid application development),


"Such an approach"

greg0ire · 2018-03-18T10:45:30Z

docs/en/tutorials/getting-started.rst

+but may bring problems later down the road, because providing such an
+easy way to modify any field in your entity means the entity itself cannot
+ensure it's in valid state. Having entity in invalid state is dangerous,
+because it's one step away from being implicitly saved in database, thereby


How about:

Having any object in an invalid state can lead to bugs that will be even harder to troubleshoot and fix if that broken state is persisted to a database and detected later on when the corrupted data is loaded.

greg0ire · 2018-03-18T10:46:31Z

docs/en/tutorials/getting-started.rst

        }

-        public function getName()
+Here, we avoid all possible logic from the model and only care about injecting
+data into it without validation nor consideration about the object's state.


"without any validation but the one provided by the type hints"

greg0ire · 2018-03-18T10:48:31Z

docs/en/tutorials/getting-started.rst

+
+            public function ban(\DateInterval $duration): void
+            {
+                assert($duration->invert !== 1);


greg0ire · 2018-03-18T10:49:49Z

docs/en/tutorials/getting-started.rst

+validated before being sent to the object for update.
+
+By using DTOs, if we take our previous ``User`` example, we could create
+a ``ProfileFormUser`` DTO object that will be a plain model, totally


DTO object expands to "data transfer object object"

greg0ire · 2018-03-18T10:50:26Z

docs/en/tutorials/getting-started.rst

-should not set this value since it represents a database id value.
-(Note that Doctrine itself can still set the value using the
-Reflection API instead of a defined setter function)
+There are several advantages to using such model:


should be "such a model", BTW

Pierstoval · 2018-03-18T12:14:11Z

I made another big update, thanks a lot to all reviewers, it makes me both improve my english and my understanding of how we explain such a complex design as DTOs and rich entities 😄

Ocramius

🚢 this is good as-is IMO (besides more nitpicking that I will avoid here).

If anybody has additions/suggestions, please send more PRs :-)

javiereguiluz · 2018-03-18T21:19:50Z

docs/en/tutorials/getting-started.rst

+  become much harder, and you might be aware of the bug too late to fix it in a
+  proper manner.
+
+implicitly saved in database, thereby leading to corrupted or inconsistent


@Pierstoval this phrase looks a missed leftover. Is it intended?

Dropped in #7137

javiereguiluz · 2018-03-18T21:26:07Z

docs/en/tutorials/getting-started.rst

-language. The metadata language describes how entities, their
-properties and references should be persisted and what constraints
-should be applied to them.
+There are several advantages to using such a model:


For the previous "anemic entities" you mentioned 1 advantage (RAD) and 4 drawbacks ... here you mention 4 advantages and 0 drawbacks. Do these "rich entities" really have no drawbacks? Thanks!

Not really: being able to have the database as an implementation detail is primary the reason for using a data mapper over other types of persistence layers, so this approach goes much much closer to the business requirements. It still has the flaws of mutable state management, but that's inherent from RDBMS-backed applications in general.

tomasfejfar · 2018-03-18T22:59:00Z

docs/en/tutorials/getting-started.rst

@@ -228,39 +227,235 @@ entity definition:
         * @var string
         */
        protected $name;


The vairable is protected.

When creating entity classes, all of the fields should be private.

tomasfejfar · 2018-03-18T23:01:09Z

docs/en/tutorials/getting-started.rst

+Rich entities should represent **behavior**, not **data**, therefore
+they should be valid even after a ``__construct()`` call.
+
+To help creating such objects, we can rely on ``DTO``s, and/or make


tomasfejfar · 2018-03-18T23:02:30Z

docs/en/tutorials/getting-started.rst

+
+Example of a rich entity with proper accessors and mutators:
+
+.. configuration-block::


This does not render!

There needs to a an empty line after the .. code-block:: php

Ocramius · 2018-03-18T23:03:42Z

@tomasfejfar this patch is already merged: send further PRs to fix pending issues 👍

tomasfejfar · 2018-03-18T23:09:18Z

docs/en/tutorials/getting-started.rst

-should be applied to them.
+There are several advantages to using such a model:
+
+* **Entity state is always valid**. Since no setters exist, this means that we


tomasfejfar · 2018-03-18T23:12:30Z

docs/en/tutorials/getting-started.rst

+The next step for persistence with Doctrine is to describe the structure of
+the ``Product`` entity to Doctrine using a metadata language. The metadata
+language describes how entities, their properties and references should be
+persisted and what constraints should be applied to them.


The section following this edit mentions again setters and getters. That's IMO confusing.

morozov · 2018-03-21T19:24:43Z

docs/en/tutorials/getting-started.rst

        {
-            $this->name = $name;
+            public function updateFromProfile(ProfileEditingForm $profileForm): void


While the ProfileEditingForm is defined above as a DTO, the code itself reads as the domain object (user) depending on the application logic (form). This way, it violates the Open/closed principle: every time a new form is added, the User class needs to be updated to enable its mutation by the form. Does the user really have to accept multiple types of DTO or at least, could all forms be represented by one DTO type?

BTW, this code is not rendered on the website:

Majkl578 added Documentation WIP labels Dec 18, 2017

fesor reviewed Dec 20, 2017

View reviewed changes

Majkl578 reviewed Dec 23, 2017

View reviewed changes

This was referenced Jan 10, 2018

Best Way to Group Entities in a Project #6978

Closed

Symfony Flex - Generating entity doctrine/DoctrineBundle#729

Closed

lcobucci reviewed Jan 15, 2018

View reviewed changes

marek-pietrzak-tg reviewed Jan 15, 2018

View reviewed changes

greg0ire reviewed Jan 19, 2018

View reviewed changes

Ocramius mentioned this pull request Jan 21, 2018

postgres multiple schema creates invalid entities #7000

Closed

Pierstoval added 4 commits March 16, 2018 19:53

WIP to document using DTOs and entities as ValueObjects

5f7210b

Make updates after @greg0ire, @mheki and @ostrolucky's comments

042cff9

More english misunderstanding fixes

86dc7f4

Moar fixes, thanks @greg0ire

31e1923

Ocramius suggested changes Mar 17, 2018

View reviewed changes

Ocramius assigned Pierstoval Mar 17, 2018

greg0ire requested changes Mar 18, 2018

View reviewed changes

More and more fixes \o/

3ce3aa9

Ocramius approved these changes Mar 18, 2018

View reviewed changes

Ocramius added this to the 3.0 milestone Mar 18, 2018

Ocramius merged commit 8836954 into doctrine:master Mar 18, 2018

Pierstoval deleted the dto-and-vo branch March 18, 2018 17:20

javiereguiluz reviewed Mar 18, 2018

View reviewed changes

tomasfejfar reviewed Mar 18, 2018

View reviewed changes

Ocramius removed the WIP label Mar 18, 2018

morozov reviewed Mar 21, 2018

View reviewed changes

Majkl578 mentioned this pull request Mar 23, 2018

Deprecating doctrine:generate:entities and pointing to MakerBundle doctrine/DoctrineBundle#790

Merged

Ocramius mentioned this pull request Mar 23, 2018

Remove references to entity generation, replace by proper entity modelling symfony/symfony-docs#8893

Closed

greg0ire removed this from the 3.0.0 milestone Jun 27, 2021


		public function getId()
		When creating entity classes, all of the fields should be protected or private (not public).


		.. note::

		Setters are unrelated to Doctrine itself, because the ORM does not


		Example of a rich entity with proper accessors and mutators:

		.. configuration-block::

Documentation about getters/setters to DTOs and Value Objects #6902

Documentation about getters/setters to DTOs and Value Objects #6902

Conversation

Pierstoval commented Dec 18, 2017

Majkl578 commented Dec 18, 2017 • edited Loading

fesor commented Dec 18, 2017 • edited Loading

Ocramius commented Dec 19, 2017 via email

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fesor Dec 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fesor Dec 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ostrolucky commented Dec 30, 2017

fesor commented Jan 2, 2018 • edited Loading

Pierstoval commented Jan 2, 2018

fesor commented Jan 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

greg0ire Jan 19, 2018 • edited Loading

Choose a reason for hiding this comment

greg0ire Jan 19, 2018 • edited Loading

Choose a reason for hiding this comment

Pierstoval commented Mar 16, 2018

Pierstoval commented Mar 16, 2018

greg0ire commented Mar 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

greg0ire Mar 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

greg0ire commented Mar 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Pierstoval commented Mar 18, 2018 • edited Loading

Ocramius left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ocramius commented Mar 18, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Majkl578 commented Dec 18, 2017 •

edited

Loading

fesor commented Dec 18, 2017 •

edited

Loading

fesor Dec 20, 2017 •

edited

Loading

fesor Dec 20, 2017 •

edited

Loading

fesor commented Jan 2, 2018 •

edited

Loading

fesor commented Jan 2, 2018 •

edited

Loading

greg0ire Jan 19, 2018 •

edited

Loading

greg0ire Jan 19, 2018 •

edited

Loading

greg0ire Mar 18, 2018 •

edited

Loading

Pierstoval commented Mar 18, 2018 •

edited

Loading