0

The current architecture is based on WCF services which populate DTO objects from DB and return them.

Some methods return complete object graph, some only partial. If completely populated, some object graphs would be extremely large - so that is not an option for all cases.

How to document what properties of the DTO object out of many are populated and which aren't? It's a .NET shop and XML comments don't provide enough flexibility to document not-always-populated properties. How do others tackle this challenge?

Ex: To the client an Invoice object is the same, whether it has all properties populated or not.

One idea proposed is to generate XSD schema for an object with only the populated properties. This doesn't seem like a "good/usable" documentation, although technically correct.

EDIT: I found that UML might be a better alternative than XSD as it's more readable. Is there a quick way to go from XML -> XSD -> UML (or another diagramming paradigm)?

Leon
  • 3,311
  • 23
  • 20

1 Answers1

2

In one of our systems we actually use 2 models: one is internal which is all completed and mature, another is used in services like contract between our system and external parties. we created auto generated mappers and fillers. This gave us possibility to change our internal representation and structure of the object model without breaking external system's data contract.

wałdis iljuczonok
  • 662
  • 5
  • 8
  • This seems to be the "right" way to do this. We're trying to reduce code duplication by reusing same model everywhere with WCF allowing for reuse of classes instead of creating proxies. Otherwise we would have dozens of proxies and no easy way to map between them even though they represent subsets of the same data. – Leon Feb 04 '11 at 17:54