La mejor alternativa para el tipo de valor anulable .NET para el servicio consumible de Java

Question

Estamos creando algunos servicios WCF que inicialmente serán consumidos por clientes .NET pero que en el futuro serán consumidos por clientes Java.

Como tal, queremos evitar el uso de cualquier tipo de datos en la interfaz que Java no admita.

El específico que conocemos es tipos de valores que aceptan valores numéricos.

Una sugerencia es que podemos admitir estos mediante el uso de una cadena para representar, por ejemplo, una int nullable. Y, por lo tanto, la cadena vacía representa nulo; de lo contrario, existe un requisito de que la cadena debe poder analizarse como un int.

¿Alguien puede recomendar una mejor alternativa, o es esto lo que haría?

Answer 1

Un enfoque que se utilizó en un proyecto en el que participé hace unos años (también combinación de .NET/Java) fue agregar propiedades de indicador: NumProperty y NumPropertyIsNull. No era particularmente bonito, pero funcionó.

Como nodo lateral, creo que al final no hemos podido encontrar un solo caso de negocio donde la diferencia entre 0 y null realmente importaba.

Answer 2

me había esperanza de que si se puede exponer a un número entero anulable a través de WCF, que cualquier cosa que consume desde Java utilizará los tipos de contenedor - Integer en lugar de int, Byte en lugar de byte etc Por supuesto, estos son los tipos de referencia mientras que los tipos de valor anulables en .NET siguen siendo tipos de valor, por lo que obtendrá más presión de GC y generalmente será menos eficiente, pero no hay mucho que pueda hacer al respecto dado que Java no admite el valor definido por el usuario tipos.