根据输入/输出更改 WCF Web 服务上的 DataMember 属性?
场景:数据模型中的实体与各种信息一起传递到 WCF Web 服务中,保存到数据库中,然后返回完全填充了附加信息的对象。
public class Request
{
public virtual Guid RequestID { get; set; }
public virtual string RequestType { get; set; }
public virtual System.DateTime CreatedDate { get; set; }
//More properties here populated from DB
}
[OperationContract]
Request CreateRequest(Request input);
在此示例中,仅当将记录插入数据库时才会填充 RequestID 和 CreatedDate,因此在初始请求期间不应可见。然而,当对象返回时它们应该是可见的。
我们当前采用的方法是在 Web 服务实现项目中创建两个从实体继承的类(RequestInput、RequestOutput)。 然后,我们将在所需的各种属性上添加 [DataMember] 属性,并在应忽略的属性上添加 [IgnoreDataMember] 属性。
这是正确的方法吗?
Scenario: An entity from data model is passed into a WCF Web Service with various information, saved into a database and then returned back with the object fully populated with additional information.
public class Request
{
public virtual Guid RequestID { get; set; }
public virtual string RequestType { get; set; }
public virtual System.DateTime CreatedDate { get; set; }
//More properties here populated from DB
}
[OperationContract]
Request CreateRequest(Request input);
In this example, the RequestID and CreatedDate are populated only when the record is inserted into the database, and therefore should not be visible during the initial request. They should be visible when the object is returned however.
The current approach that we are going with is to create two classes (RequestInput, RequestOutput) in our web service implementation project which inherit from the entity.
We will then add [DataMember] attributes on various properties that are required and [IgnoreDataMember] on those that should be ignored.
Is this the correct approach?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我不会说这是正确或不正确的方法。但更常见的是使用类似的名称
,并且
请求和响应理想情况下应该与您在客户端和服务器中使用的模型表示解耦 - 即您有一个外观或适配器将它们映射到您的模型您的服务代码。
这符合我的做法 - 但这是非常主观的,取决于实体的大小等 - 您可能希望以某种方式涉及自动映射器。
I wouldn't say it is a correct or incorrect way. But it is more usual to use names something along the line of
and
the Request and Response should ideally be decoupled from the model representation you are using in the client and the server - ie you have a facade or adaptor that maps them to your model from your service code.
this is along the lines of how I would do it - but this is very subjective dependant on size of entities etc - you may want to involve an auto-mapper somehow.