Marco, Thx for you time.
Regards, Sérgio On Wednesday, June 17, 2015 at 9:24:56 AM UTC+1, Marco Pivetta wrote: > > On 17 June 2015 at 09:19, Sérgio Amorim <[email protected] <javascript:>> > wrote: > >> Marco, >> >> Thanks once again. >> >> It's always a trade off between control on the app vs complexity of the >> library, but if is not possible then.. it's not. At least now I know! :) >> >> The problem comes down to doing a query in the DAL returning that object >> up the chain and nothing will prevent another call to the database access >> layer... so it goes out of control of the DAL. Potentially, a view layer >> could promote calls to the database and there's nothing that can be done in >> the layers between to "control" it. All because the entity model are wrap >> in a proxy that does this and you "can't turn off". >> > > The fact is that I don't see a reason why you'd ever need control over the > DAL from upper layers. > > >> By the way, Entity Framework (DBAL of the .NET world) enables you to do >> this by disabling the proxy and hydrating directly the model entities. Of >> course this has it's side effects, like you potentially could think that >> there are no Qux, because the collection won't be populated, when there >> are. But you have the control of it. >> > > This seems broken and hugely dangerous to me: you are now hydrating broken > models, which may cause incredibly complicated issues. > Consider an example where you have [BankAccount] 1 -> n [Transactions] and > an an empty transaction list (hydrated incorrectly due to filtering or > explicit removal of the hydration via flags): it is now impossible to get > the correct bank account balance. > It's a can of worms, and we will unlikely go down that way, ever: just use > array hydration and DTOs instead of entities instead. > > Do you think that is feasible to create a proxy factory that disables >> this? Or a custom hydration that doesn't use the proxy? >> > > As I explained above, this is plain dangerous and I don't see a practical > use-case for it except for SoC leakage between layers (which shouldn't > happen). > > The ORM is just a complex serializer that acts on an open DB connection > rather than on a serialized string: don't try to make it do more than what > it should do and you'll just be fine ;-) > > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > -- You received this message because you are subscribed to the Google Groups "doctrine-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/d/optout.
