cancel
Showing results for 
Search instead for 
Did you mean: 

OCC Architectural question about version 2.

Former Member
0 Kudos
1,856

I wonder what is everyone opinion about one simple fact.

OCC or a.k.a. commercewebservices version 2 is one of the worst architectures I have seen in Hybris.

Let me explain: Version 1 is fine, you have controllers, you call facades, they do the conversion you get a result as Data object, it is the same on the storefront it is an ok architecture it is from pre sap days when Hybris was not in SAP so it is good.

Version 2 however uses ANOTHER layer of conversion. So you convert your models to Data objects in the facades THEN you get the DATA which is ALREADY a DTO and you convert the DATA to WsDTO what is the point it is already a DTO !?

So right now if you need to add a field in a model and return it in version 2 you have to:

  • change the model

  • change the bean for the Data object new property

  • change the converter/populator that is used by the facade. (here you were done in v1)

  • change the WsDTO bean xml

  • change the Orika config in another xml

  • Hook everything together.

  • Debug is it an issue in the model, in the data, in the converter, in Orika (yup thats fun) in the spring config you have for orika or in your WsDTO.

  • Do it again for the next service

So please can someone explain me what is the point of using Orika to convert from an already a DTO called Data for some reason to another DTO called WsDTO for some reason. I expect in version 3 to have a RealDTO and third conversion ?

I am not sure who is the author of this but I believe this is an overkill.

My goal here is to st conversation because after all we know that no one actually helps in the experts. If there is no conversation started here I will start it on stackoverflow and twitter as well since this is an amazing joke.

P.S. I Love ORIKA but to overdesign and misuse it in such a way is just a joke, you can convert directly with orika

P.S.S. Also for some v2 services like register you still use old school populators to populate directly the Data object (like register) so why the fck do you need Orika at all !?

View Entire Topic
former_member747843
Active Participant
0 Kudos

Hi
Reasons of introducing WsDTO data layer are described here : https://help.hybris.com/1811/hcd/8c8b49a186691014aface4015d79a338.html

A new WsDTO model has been introduced in v2 of the REST API. It does not affect compatibility with v1. It was introduced to add stability to the REST API by removing the dependency to the commerce services data model. Now, changes in the commerce data model do not directly affect the REST API. It also improves flexibility by introducing a mechanism that allows control of returning fields. Therefore, consumers now have influence on what the returning WsDTO object will look like. In v2 of the REST API, you can explicitly request specific fields to be filled in an object or use a predefined set of fields.

Former Member
0 Kudos

If we change the commerce data model it will affect the rest API because the rest API uses the outcome from the conversion in the commerce data model. So changing any of the fields in the Data objects will change the Rest API or even break it.

Why then instead of introducing ANOTHER layer of conversion not a new facades has been made that uses ORIKA to directly convert the models to the new WsDTO which was the proper way to go. Also the Sidi has done a GREAT job doing ORIKA and is great replacement of the old populator/convertors idea but the way how it is misused here is just terrible.

former_member747843
Active Participant
0 Kudos

I don't think that converting directly from models using Orika would be so easy. It for sure would be much more complicated and allowing consumer influence it directly by fields parameter could be also big security hole. Commerce layer contains also quite a lot logic - writing new facades and conversion logic for everything seems like quite a big effort and could lead to inconsistency in how standard accelerator and such based on rest api works.