Archived

This forum has been archived. Please start a new discussion on GitHub.

Object Conversion Problem

Ice generates object definitions from slice defined files, in practical applications, these objects can not be used in other layers. For example, an application uses ice to transfer data to storage layer, and storage layer uses ORM to define data models, the problem is the conversion between the two type of models is complex and inefficient. How to make the conversion conveniently and efficiently? Are there some patterns to design this type of application?

Comments

  • benoit
    benoit Rennes, France
    Hi,

    Ice provides a storage mechanism (Freeze) that allows to store instances of Slice types such as structs and classes. Did you consider this option rather than using a relational database?

    Otherwise, I'm not aware of any specific pattern to help mapping Slice types to a relational model. That said, the Slice language is very similar to most OO languages with respect to data modeling so any ORM pattern should fit. You will have to code the the conversion layer by hand. Automating the code generation for this layer is certainly possible but would require a lot more investment so this is something I would consider only for applications with very large data models.

    Cheers,
    Benoit.
  • Thanks for the answer. Currently, we want to apply the ICE in our system for data transmission, the data finally stores in Oracle, and using something like Hibernate ORM mapping, so we should convert the ICE data model to the ORM data model, and if we code the conversion by hand, it will be very troublesome in the future maintenance. In the upper layer, we should support multi program language, but we don’t want to use webservice, the perfect solution is to define one data model for all layers (data layer, transmission layer, application layer). Can ICE achieve our purpose, or are there any alternatives?
  • benoit
    benoit Rennes, France
    Hi,

    While it is much simpler to use the same types for data, transmission and application layers, it also has some disadvantages: it might not be optimal and inconvenient to use.

    Slice types are typically designed and optimized for transmission over the wire. You also typically design them for use by both a client and a server. You might not use the same Slice types for communication between a client GUI and a server and this same server and an administrative tool or another backend server.

    Data types are designed for storage and often an additional layer is needed on top of them to add the application logic and hide the storage details which are still visible despite the object-relational mapping.

    In any case, one way to achieve what you want could be to define your types as Slice structs (which are also POJOs in Java). This will allow clients with different language mappings to communicate with your server using those structs and store them with Hybernate using a mapping file.

    Making improvements to the slice2java translator to allow specifying Hybernate/Java Persistence annotations is also a possibility. If you are interested in sponsoring such a feature, this is something we could consider, please contact as at info@zeroc.com if that's the case.

    Cheers,
    Benoit.