Not when I look at it. A customer can be a Account of a system, and have a property (ex. the Email Address, customer number) that serves as a unique identifier (accountIdentifier). I’m not a fan of the decoupling today, because I have to take care of the account identifier 2 places, if I use the email address of a Customer as account identifier.
If you try to look at it a tiny little bit differently, you’ll realize that it is much easier to work with (at least in the Flow world).
You don’t need to “decouple” it. If you really have that 1:1 mapping between Customer and Account, just make it a 1:1 relation. For example like this:
/**
* @Flow\Entity
*/
class User
{
/**
* @var Account
* @ORM\OneToOne
*/
protected $account;
public function getEmailAddress()
{
return $this->account->getAccountIdentifier();
}
// ....
Wouldn’t that work for you?
Just a small example: we use signup via E-Mail, Google, Facebook, Twitter. So the identifier might be a social media ID or just the E-Mail. This also allows the user to connect multiple solutions (e-mail and facebook - because that gives more options like “what your friends liked” etc.) We also use the Neos.Party Package and have the E-Mail address saved there. Yes we need to see that they don’t split apart for the E-Mail Login but i really love how easy it was to implement with Flow.
1 Like