Hi Marco, Thank you for your reply.
I understand what you are proposing but I have a hard time to try to solve is the duplication of code. In one application that I have to maintain I have to deal, for example, with a process where the user selects a list of Products, retrieved from the DB, and depending on the operation he demands, I have to process right away or wait for an external system to notify me of the result (via postback to a different URL). The user will either see the OK your request has been processed or you request is in our queue and you will be notified... When an external system postbacks to me I have to take this list, stored in the db, process it - feeding the Product entities. In my idea I would have the same method that takes the list of Products, either they came fresh from the DB or unserialized from the initial request. That is what I do using an internal db layer that pretty much does the mysqli query and returns entities using a map from the column name to the property name. But I want to remove this in favor for Doctrine ORM/ODM. In the approach suggested I would define and use Doctrine to retrieve the products from the DB but upon saving for further processing I'd have to create something to store it as the ValueObjects that can be safely serialized/deserialized. And my method to process would have to accept both types of lists (the Products from the DB and the Products Value Objects). I hope there is something that can be done without having to do such. On Sat, Apr 4, 2015 at 10:58 PM, Marco Pivetta <[email protected]> wrote: > Hi Mario > > On 5 April 2015 at 03:51, mbneto <[email protected]> wrote: > >> Hi Marco, >> >> Thank you for the reply. As part of some applications I see the >> following happening: >> >> 1st - Request >> a) fetch data from persistence layer >> b) map them to Objects >> c) use some in the request itself >> d) save some in a session layer >> >> 2nd - Request (part of the same application process - perhaps the submit >> of the form) >> a) restore the session data >> b) update the Objects based on the form data >> c) persist some of the objects back - updating the content >> >> While not all objects would have the Doctrine annotation, some may have, >> even if I use them for read only purposes. >> >> Right now I can do it fine because they are POPO and I map them manually >> when I first do the search. After this I can serialize/deserialize at will. >> >> Of course the idea is to use Doctrine to prevent me from having to do >> such mapping manually - and to have all the extra features Doctrine >> provides. >> >> In this scenario what would be me course of action? >> > > This is what most of us ended up with, but it's actually a mess to deal > with, and that with or without ORM. > > The best approach, in my opinion, and especially with multi-step forms, is > to have form-specific DTOs/ValueObjects that you can actually safely store > in session data or in a transient storage location that you can reference > somehow. > > This greatly simplifies the entire process, and is also much safer and > reliable than just making complex forms interact with your persistence > layer (which, honestly, is quite problematic in first place). > > Greets, > > 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. > -- 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.
