I've figured out how to test the download mapping for objects, but I'm at an utter loss to test the inverse -- that objects properly serialize back into JSON.
You should be able to use RKMappingTest in just the same way for both serialisation and deserialisation. Supply a request mapping instead of a response mapping. The source object will be one of your model classes. The destination object will be a mutable dictionary. Expectations are set in the same way.
Related
In my Spring boot project I use hibernate and basically we have three kinds of objects
DTO object which is used in the controller layer.
Business Object - business object is what we use throughout our application.
Entity/Domain Object - which is used in JPA layer.
When we are ready to save the data we turn the Business Object to Domain/Entity Obj
And when we are ready to send it to the client/controller we can convert the entity object to Business Obj and this Business object in turn to DTO Obj.
Ideally I was told that the conversion logic of changing BOs to -> (DTOs and entities) and vice versa reside in the BOs itself?
How do we achieve this in an efficient way? Can anyone help with any examples?
I love to use Mapstruct in all the projects that I am participate in
There are several things that I adore most about it:
Obviously, you spend less time on coding the conversions (have a look at 'MapStruct in 2 Minutes' on the main page)
If you the property names in your class that you want to transform to and from are the same then you write even less of code.
It integrates well with spring, so you don`t need to declare any beans or something, just specify that it is "spring" component model.
You have variety of ways how to map entities - create new, update existing with values from DTO(for example).
Children objects are easily mapped as well. It has internal mechanism that tries to pick up the right mapper method in other mappers. Or you can specify its name yourself arbitrary.
Though you can also have a look at ModelMapper as well. Pretty similar library, but less used by myself. So cannot make any particular advice.
There is no silver bullet for this task, but you can consider using model mapper for that; that's the simple example https://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application
Am working on finding the differences between two Json objects and storing the respective Diff in Json format(using Javers), so that can be retrieve later and presented to the user in a meaningful manner. Now, the challenge is, the Affected Object(where the change has happened) is not being serialized during serialization.
I understand that it is not possible to retrieve the domain objects from Diff.
Could see that the "affectedCdo" has been marked as transient not allowing to serialize it.
Any other alternative for doing this?
Thanks,
Ravi.
Restoring orginal domain objects from persisted snapshots will be possible when we implemen the shadows feature in JaVers. We are working on it. https://github.com/javers/javers/issues/133
Most (almost all?) validation frameworks are based on reading object's property value and checking if it obeys validation rules.
Do we really need it?
If we pass valid parameters into object's constructor, property setters and other methods, object seems to be perfectly valid, and property value checks are not needed!
Isn't it better to validate parameters instead of properties?
What validation frameworks can be used to validate parameters before passing them into an object?
Update
I'm considering situation where client invokes service method and passes some data. Service method must check data, create / load domain objects, do business logic and persist changes.
It seems that most of the time data is passed by means of data transfer objects. And property validation is used because DTO can be validated only after it has been created by network infrastructure.
This question can spread out into wider topic. First, let's see what Martin Fowler has said:
One copy of data lies in the database itself. This copy is the lasting
record of the data, so I call it the record state.
A further copy lies inside in-memory Record Sets within the application. This data
was only relevant for one particular session between the application
and the database, so I call it session state.
The final copy lies
inside the GUI components themselves. This, strictly, is the data they
see on the screen, hence I call it the screen state.
Now I assume you are talking about validation at session state, whether it is better to validate the object property or validate the parameter. It depends. First, it depends on whether you use Anemic or Rich Domain Model. If you use anemic domain model, it will clear that the validation logic will reside at other class.
Second, it depends on what type of object do you build. An Framework / operation /utility object need to have validation against object property. e.g: C#'s FileStream object, in which the stream class need to have valid property of either file path, memory pointer, file access mode, etc. You wouldn't want every developer that use the utility to validate the input beforehand or it will crash in one operation, and giving wrong error message instead of fail fast.
Third, you need to consider that "parameter can come in many sources / forms", while "class / object property only has 1 definition". You need to place the parameter validation at every input source, while object property validation only need to be defined once. But you also need to understand the object's state. An object can be valid in some state (draft mode) and not in other state (submission mode).
Of course you can also add validation into other state level as well, such as database (record state) or UI (screen state), but it also have different pros/cons.
What validation frameworks can be used to validate parameters before passing them into an object?
C#'s ASP.Net MVC can do one kind of parameter validation (for data type) before constructing into an object, at controller level.
Conclusion
It depends entirely on what architecture and kind of object you want to make.
In my experience such validations were done when dealing with complex validation rules and Parameter object. Since we need to keep the Separation of concerns - the validation logic is not in the object itself. That's why - yes we
we really need it
What is more interesting - why construct expensive objects and later validate them.
I can't seem to find a concrete example of how to write a custom converter for Restlet. I'm having an issue with an object containing an ArrayList of a base type. (ie List )
I've been able to painstakingly do the conversion by reading in the object as JSON, converting it to a JSONObject and processing each field individually to create the representation I need on the deserialization. This seems very odd that I'd have to do this.
any help would be appreciated.
I'm trying to figure out how to decide when to use NSDictionary or NSCoder/NSCoding?
It seems that for general property lists and such that NSDictionary is the easy way to go that generates XML files that are easily editable outside of the application.
When dealing with custom classes that holds data or possibly other custom classes nested inside, it seems like NSCoder/NSCoding would be the better route since it will step through all the contained object classes and encode them as well when an archive command is used.
NSDictionary seems like it would take more work to get all the properties or data characteristics to a single level to be able to save it, where as NSCoder/NSCoding would automatically encode nested custom classes that implement the NSCoding interface.
Outside of it being binary data and not editable outside of your application is there a real reason to use one over the other? And along those lines is there an indicator of which way you should lean between the two? Am I missing something obvious?
Apple's documentation on object graphs has this to say:
Mac OS X serializations store a simple hierarchy of value objects, such as dictionaries, arrays, strings, and binary data. The serialization only preserves the values of the objects and their position in the hierarchy. Multiple references to the same value object might result in multiple objects when deserialized. The mutability of the objects is not maintained.
…
Mac OS X archives store an arbitrarily complex object graph. The archive preserves the identity of every object in the graph and all the relationships it has with all the other objects in the graph. When unarchived, the rebuilt object graph should, with few exceptions, be an exact copy of the original object graph.
The way I interpret this is that, if you want to store simple values, serialization (using an NSDictionary, for example) is a fine way to go. If you want to store an object graph of arbitrary types, with uniqueness and mutability preserved, using archives (with NSCoder, for example) is your best bet.
You may also want to read Apple's Archives and Serializations Programming Guide for Cocoa, of which the aforelinked page on object graphs is a part, as it covers this topic well.
I am NOT a big fan of using NSCoding/NSCoder/NSArchiver (we need to pick a name!) to serialise an object graph to a file.
Archives created in this way are incredibly fragile. If you save an object of class Foo then by golly you need to make sure when you load the data back in you have a class Foo in your application.
This makes NSCoder based serialisation difficult from the perspective of sharing files with other applications or even forwards compatibility with your future application.
I forgot to list what I would recommend.
NSCoding can be ok in certain situations: if you're just doing something quick and simple (although you do have to write a lot of code - two methods per class to be serialised). It can also be ok if you're not worried about compatibility with other applications.
Export/import via property lists (perhaps using the NSPropertyListSerializaion class) is a fine solution. XML based plists are easy to create and edit. Main advantage to plists is that you're not tying the file format to just your application.
You can also create your own XML based file format and read/write to it using NSXMLDocument API and friends. This really isn't much more work than using property lists.
I think you're a bit confused, NSDictionary is a data structure, it also happens to implement the NSCoding protocol. So in essence, you could either put all your data into a NSDictionary and have that encode itself later on, or you can implement the NSCoding protocol and encode your object tree using the NSCoder API. Based on the type of NSCoder object passed in to the encodeWithCoder: method, is the output of your encoding.