1 clarification... "*So, I do think a Data Conversion (and Formatting) service could be handy in the cases where the data needs to be converted for indexing, querying or other data access operations (e.g. Functions), that has not quite reached the application yet that needs to be handle in an application specific manner."*
On Thu, Jan 26, 2017 at 1:14 PM, John Blum <jb...@pivotal.io> wrote: > Looking at this problem on the flip-side, from an application's > perspective (which can also be equated to data going out from the data > store)... > > *Data Conversion* (and *Formatting* for that matter) is quite generic and > has little to nothing to do with JSON, XML or any other format. > Technically, handling different data formats is a data > conversion/formatting implementation detail, and usually quite application > specific. > > Even the same data format can be converted and typed (i.e. given a type) > differently based on context, rules, or certain conditions, and so on, > which is often handled by registering more than 1 converter/formatter. > > Therefore, DC&F is all about, I have some "type" my application uses to > represent/model the (requested) data coming in and I want to "map" the data > I received (regardless of format) to the type my application uses based on > how it wants to process that data. There maybe 1 type or several (think > projections) depending on the views my application presents. > > This can apply all the way down to the primitive type level of individual > fields all the way up to and including more complex, composed types. > > For instance, my application type might represent a date String as a Date, > a (Local)DateTime, a Timestamp, a Long, who cares. I might also format > that type based on a view that takes Locale into account, etc. In a more > complex case, say a phone number String, well, that certainly varies by > country and I might have different complex type implementations to > represent phone numbers in different, again, Locales. > > So, it really does not matter if the document (JSON, XML or otherwise) > sent or received has a schema, or other type meta-data that says what the > individual, composed field types are in an entity of the data. The > application is still free to convert that data as it sees fit, when it > needs to be converted. > > So, I do think a Data Conversion (and Formatting) service could be handy > in the cases where the data needs to be converted for indexing, querying or > other data access operations (e.g. Functions), that has not quite reached > the application yet. > > For that, there many excellent and existing Data Conversion/Formatting > services and frameworks available. > > *Spring* has had first-class support [1] for this concern since the > beginning, which touches on another import aspect of data conversion... > validation! > > Additionally, Apache Commons itself has had Conversion functionality for > years as well, in BeanUtils [2]. > > Food/ideas for thought. > > -John > > [1] http://docs.spring.io/spring/docs/current/spring-framework-reference/ > htmlsingle/#validation > [2] http://commons.apache.org/proper/commons-beanutils/ > javadocs/v1.9.3/apidocs/org/apache/commons/beanutils/ > converters/package-frame.html > > -- -John john.blum10101 (skype)
