Hi Mario, I don't have an overview of what you are doing, or better I didn't understand what you are doing it (and why the serialization is required).
Could you make a pseudo-code example (under 30-ish LOC)? Just to understand the concept of what you are trying to do. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On 4 May 2015 at 03:09, mbneto <[email protected]> wrote: > 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. > -- 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.
