why did i choose to use typed dataset in web service?

pros

  • vs.net support on xsd and class generation via xsd.exe (drag and drop from data model to dataset plus some final touch)
  • existing data access framework support on mapping xsd to relational data and vise versa using data adapter (minimum coding required)
  • updategram that works well with the mappings defined in 2 (works really well for applications and no much coding required)
  • vs.net generated proxy works!
  • cons

  • locked in on .net (mitigation – provide alternative interface based on xsd for j2ee if required; there’s a way to transform typed dataset into a similar xsd and generate corresponding wsdl; however, it works best for readonly data since there’s no simple way to map the returned data back to relational data w/o writing additional codes )
  • increased data traffic due to schema being serialized (limit dataset usage to minimum; typed dataset for updatable data only)
  • in some cases, typed dataset is too vague or loose specially when there’re more than one table defined (this point is counter balanced by the no 2 in pros. gain something then lose something else …)
  • i ditched the idea of separating schema from dataset since it would require both ends to deal with schema anyway.
    i ditched the idea of not using dataset since it would require us to write tons of mapping code for relational data and updategram.

    everything works if designed and used properly. besides, everying around us is galaxy apart from soa world anyway.