用于对象集合或“has-a”的 SOA WCF 类设计对象情境
我们正在从头开始为将通过 WCF 公开数据的应用程序设计一个对象模型。我们想知道如何处理其中包含对象集合的对象的情况。例如,具有地址对象集合的联系人对象。
contact - list<address>
我们是否应该有一个包装对象,例如“AddressCollection”,它具有自己的属性,例如“hascollectionloaded”,用于集合的延迟加载以及我们尚未想到的其他内容,或者我们应该只依赖于列表< ;>如上所述?
contact - AddressCollection - list<address>
- hasBeenFullyLoaded
- preferredObjectLoaded
- somethingElsePertinent
对于上面的示例,我们可以让 AddressCollection 继承自实现“hasbeenloaded”和“somethingElsePertinent”属性的抽象基类或接口吗?
或者,甚至在联系人对象本身“hasaddressloaded”上实现另一个 bool 属性。
contact - list<address>
- hasaddresscollectionloaded
同样,如何在联系人上实现不一定是集合的自定义对象?例如:
Contact - Status
或
Contact - StatusObject - Status
- hasStatusLoaded
- somethingElseWeWantToKnow
We are designing an object model from scratch for an application that will expose data via WCF. We are wondering about how to handle the case where objects that have a collection of objects within them. For example, a contact object with a collection of address objects.
contact - list<address>
Should we have a wrapper object, something like "AddressCollection", that has properties of its own like "hascollectionloaded", for lazy loading of the collection, and other things we havn't thought of yet, or should we just rely on the list<> as above?
contact - AddressCollection - list<address>
- hasBeenFullyLoaded
- preferredObjectLoaded
- somethingElsePertinent
For the example above, could we let the AddressCollection inherit from an abstract base class or interface implementing the "hasbeenloaded" and "somethingElsePertinent" properties?
OR, even implement another bool property on the contact object itself "hasaddressloaded".
contact - list<address>
- hasaddresscollectionloaded
Likewise, how to implement a custom object on the Contact that isn't necessarily a collection? For example:
Contact - Status
OR
Contact - StatusObject - Status
- hasStatusLoaded
- somethingElseWeWantToKnow
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你的问题有点模棱两可,但我会尝试一下。希望我们能够通过一些来回给您带来答案。
首先,如何使用 WCF 返回集合并不重要。 DataContractSerializer 将在线上正确序列化它们。对于.Net 客户端,他们可以维护原始集合类型。其他订阅者(例如 Java)将获得一个数组。
我的第一个建议是:
A) 使用契约优先开发来创建消息。您的服务应该是自主的,并为每个调用提供单独的请求和响应。这将为以后提供更大的灵活性,也将引导您做出更好的设计。
B) 你真的不应该向外界公开List,而应该公开Collection 或ReadOnlyCollection。
希望这将为您指明正确的方向。如果没有,也许我们可以弄清楚您的最终目标是什么,然后我们可以从那里开始工作。
到目前为止,这就是我从你的问题中看到的全部:
You question is a bit ambiguous but I'll give it a shot. Hopefully we can get you to an answer with some back and forth.
First of all, it doesn't really matter how you return your collections using WCF. The DataContractSerializer will serialize them properly on the wire. For .Net clients they can maintain the original collection types. The other subscribers (Java for instance) will get an array.
My first suggestions would be:
A) Use Contract First development to create you messages. Your service should be autonomous and provide a separate request and response for each call. This will allow for greater flexibility later and will also lead you to a better design.
B) You really shouldn't expose List to the outside world, instead expose a Collection or a ReadOnlyCollection.
Hopefully this will point you in the right direction. If not, maybe we can figure out what your ultimate goal is and we can work from there.
So far this is all I see from your question: