DTO Layer for REST Api?

[Ulrich Lichtenegger]

Hi,

I am building a REST API with Symfony2, FOSRestBundle and JMSSerializer. I am using a relational Database together with Doctrine ORM.

Now i wonder how i would expose certain properties of my objects without polluting my Entity Layer too much. Imagine the following use-case:

• In the Database, an entity has 2 fields: a date and a foreign key to an event. (which seems to be correct in an relational db)
  
• By convention, only one of this can have a value, the other one is null (valid to date or valid to an event) 
• In doctrine, I have 2 properties which represent the state.
  
• In my api, I would like to have only one property (validTo) and another property which says which type the validTo field has. (datetype "date" or "event") 

--> How would I manage a case like this?

• Are you using something like an DTO layer for cases like this?  (Data Transfer Objects, objects with all properties that I want to expose)
• I could use VirtualProperties with JMSSerializer, but as far as I know I wont have FormType support any more when I POST an object from outside?
  

Thanks for your help!

[William Durand]

While it could be a bit overkill depending on how large your application is, I'd go for a DTO layer.

--

William Durand | http://www.williamdurand.fr

--
You received this message because you are subscribed to the Google Groups "RESTing with Symfony" group.
To unsubscribe from this group and stop receiving emails from it, send an email to resting-with-sym...@googlegroups.com.
To post to this group, send email to resting-wi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/resting-with-symfony/87954c9f-a1db-4781-9341-d3f27051ebd7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ulrich Lichtenegger]

Thanks for your reply!

Does anyone have experience with this, e.g. is there an intelligent way to create DTOs or would you just write POPOs and converter from DAO to DTO and back?

Am Dienstag, 15. Juli 2014 11:11:24 UTC+2 schrieb William Durand:

While it could be a bit overkill depending on how large your application is, I'd go for a DTO layer.

--

William Durand | http://www.williamdurand.fr

On Tue, Jul 15, 2014 at 9:27 AM, Ulrich Lichtenegger <ulil...@googlemail.com> wrote:

Hi,

I am building a REST API with Symfony2, FOSRestBundle and JMSSerializer. I am using a relational Database together with Doctrine ORM.

Now i wonder how i would expose certain properties of my objects without polluting my Entity Layer too much. Imagine the following use-case:

• In the Database, an entity has 2 fields: a date and a foreign key to an event. (which seems to be correct in an relational db)
  
• By convention, only one of this can have a value, the other one is null (valid to date or valid to an event) 
• In doctrine, I have 2 properties which represent the state.
  
• In my api, I would like to have only one property (validTo) and another property which says which type the validTo field has. (datetype "date" or "event") 

--> How would I manage a case like this?

• Are you using something like an DTO layer for cases like this?  (Data Transfer Objects, objects with all properties that I want to expose)
• I could use VirtualProperties with JMSSerializer, but as far as I know I wont have FormType support any more when I POST an object from outside?
  

Thanks for your help!

--
You received this message because you are subscribed to the Google Groups "RESTing with Symfony" group.

To unsubscribe from this group and stop receiving emails from it, send an email to resting-with-symfony+unsub...@googlegroups.com.

[Daniel Rotter]

We had the same problem, mainly with multiple translations. That's why created another layer of object, but these objects just wrap the doctrine entities. Then we only create the function we want to have exposed with the VirtualProperty of the serializer as you suggested, and in these functions we delegate the calls to the doctrine entity. You can see an example at https://github.com/sulu-cmf/SuluProductBundle/blob/feature/product-formular/Api/Product.php

I like this solution better than classic DTOs, since the conversion functions are not really good to write and look at.

[Ulrich Lichtenegger]

Looks like a nice approach, thank you for sharing, Daniel!

Does this approach still allow to use form-types? I haven't found some in the git.
(I don't know how they work internally, if they need "real" properties or if they only check for setters)

[Daniel Rotter]

Actually I can't really tell you, we don't use form types in this project.

[Di majo]

MT103/202 DIRECT WIRE TRANSFER
PAYPAL TRANSFER
CASHAPP TRANSFER
ZELLE TRANSFER
LOAN DEAL
TRANSFER WISE
WESTERN UNION TRANSFER
BITCOIN FLASHING
BANK ACCOUNT LOADING/FLASHING
IBAN TO IBAN TRANSFER
MONEYGRAM TRANSFER
IPIP/DTC
SLBC PROVIDER
CREDIT CARD TOP UP
DUMPS/ PINS
SEPA TRANSFER
WIRE TRANSFER
BITCOIN TOP UP
GLOBALPAY INC US
SKRILL USA
UNIONPAY RECEIVER

Thanks.


NOTE; ONLY SERIOUS / RELIABLE RECEIVERS CAN CONTACT.

DM ME ON WHATSAPP
+44 7529 555638