用于对象集合或“has-a”的 SOA WCF 类设计对象情境

发布于 2024-09-07 23:09:16 字数 985 浏览 4 评论 0原文

我们正在从头开始为将通过 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

一向肩并 2024-09-14 23:09:16

你的问题有点模棱两可,但我会尝试一下。希望我们能够通过一些来回给您带来答案。

首先,如何使用 WCF 返回集合并不重要。 DataContractSerializer 将在线上正确序列化它们。对于.Net 客户端,他们可以维护原始集合类型。其他订阅者(例如 Java)将获得一个数组。

我的第一个建议是:

A) 使用契约优先开发来创建消息。您的服务应该是自主的,并为每个调用提供单独的请求和响应。这将为以后提供更大的灵活性,也将引导您做出更好的设计。

B) 你真的不应该向外界公开List,而应该公开Collection 或ReadOnlyCollection。

希望这将为您指明正确的方向。如果没有,也许我们可以弄清楚您的最终目标是什么,然后我们可以从那里开始工作。

到目前为止,这就是我从你的问题中看到的全部:

[DataContract]
public class AddressResponse
{
    [DataMember]
    public Collection<Address> Addresses { get; set; }

    [DataMember]
    public string Status { get; set; }

}

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:

[DataContract]
public class AddressResponse
{
    [DataMember]
    public Collection<Address> Addresses { get; set; }

    [DataMember]
    public string Status { get; set; }

}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文