我正在使用WCF實體框架v4和使用POCO實體。我們的實體擁有大量的相關實體。一個對象可以有許多不同類型的子對象，然後又有許多不同類型的子對象。例如一輛車有一個或多個司機。每個駕駛員都有0個或多個孩子。每個小孩然後有0或很多朋友。 （可憐的孩子，有0個朋友）。這個例子有點愚蠢，但你明白了。當涉及到使用WCF的對象圖形序列化時，是否有一些最佳實踐？
如果客戶想要購買一輛汽車，那麼返回汽車列表中的驅動程序是有意義的。填充並返回每個駕駛員的孩子可能也可能沒有意義。問題在繼續。
因爲您的數據庫幾乎總是隻包含互連表（導致互連實體），我們應該序列化多少對象圖？
我不認爲有任何經驗法則，我不喜歡返回客戶端不需要的數據的想法。您的服務設計應該由提供給客戶的業務功能來驅動。所以如果你期望客戶經常只需要Car，你應該定義只返回Car的操作。如果客戶有時還需要Car with Drivers，則應定義第二個操作，該操作將返回Car with Drivers。
如果您的服務主要作爲高級別CRUD工作，那麼它可以合理地返回至少第一級相關對象，但這又只是基於提供的功能進行泛化。另一種有用的技術可以是聚合。沒有父母實體的聚合相關實體沒有意義。例如Car with Driver不會聚合，因爲Driver是獨立的實體。但是Invoice和InvoiceLine是合計的，因爲您無法定義InvoiceLine而沒有Invoice。在這種情況下，使用所有InvoiceLines返回Invoice可能很有用。這在所有情況下都不是這樣。我開始審批應用程序，允許用戶從他們的成本中心僅查看和批准發票頭和InvoiceLines，因此如果發票包含50+個InvoiceLines，但用戶被允許僅查看單行，則沒有理由將其全部轉移。
想想你的服務提供的功能，需要複雜的轉移對象將更清晰。
我做了一些Google搜索，發現下面的文章建議只與客戶要求的實體直接相關。對於其他人：Service Orientated vs Object Orientated
我認爲在大多數情況下，傳回父母和直接相關實體的想法對我們很有用。我聽到你在說什麼。總是使用一些自由裁量權。所以也許作爲一個正常的路要走，我會做父母和孩子的方法，但每次問自己，客戶現在是否想要/需要孩子？ – uriDium 2010-10-06 08:23:22