具有数据合同访问问题的 WCF 服务答案

【问题标题】：WCF service with data contract accessing issue具有数据合同访问问题的 WCF 服务
【发布时间】：2013-06-04 19:01:13
【问题描述】：

我对 WCF 编程很陌生，遇到了一些困难。

我有一个收集student 数据的客户端应用程序，然后student 数据将通过web services 存储到数据库中。

所以我在客户端有student class，当新学生到来时，我创建学生对象并分配收集的值。

将这些数据传递给服务的最合适方式是什么？

我可以遵循的选项是；

选项 1

public void InsertStudent(string id, string name, string address)  
{  
}

我觉得这不好。因为如果我必须传递数据，那么参数列表会变得很长。

选项 2

定义服务数据契约

public void InsertStudent(WcfStudent obj)  
{

}

我觉得这很好。但是我对如何发送参数有一些问题（WcfStudent）。我是否需要在客户端创建这个WcfStudent 对象并传递该对象。

WcfStudent obj=new WcfStudent()

obj.name=myStudent.name;

obj.id=myStudent.id;

client.InsertStudent(obj);

这是正确的方法吗？

请给我建议。

【问题讨论】：

是的，你是对的。创建 WcfStudent 客户端并将其传递给专门为存储它而编写的 WCF 服务操作
使用 WSDL 生成您的客户端。这将创建 RPC 以发送到 WCF 端点。
@Steve- 我有些不确定。我想确保可以在客户端创建WcfStudent。因为我已经有了具有相同数据的myStudent 对象。
@New Developer- 就像我在下面的帖子中写的那样。将 myStudent 对象映射到 WcfStudent 对象。业务逻辑中的对象与 WCF 中的对象不同（即使结构相同）也很好。就像您知道将应用程序分离到某些层一样好。
...除了间接层太多的问题。

标签： c# wcf

【解决方案1】：

当然就像你说的第二个选项更好。在 WCF 项目中，您必须创建 DataContract WcfStudent。在具有服务参考的项目中（这就是您所说的客户端），您只需执行方法 (OperationContract) InsertStudent。理论上如何创建这个对象并不重要，但我认为在你的“客户端”中还有一个名为 StudentBO 的对象并在 WcfStudent 和 StudentBO 之间创建映射或使用一些工具（例如 Automapper）是一个很好的做法。

如果您是 WCF 的新手，请阅读有关 DataContract、DataMember 的内容。

祝你好运！

更新

谈论您的评论会更好，例如：

public WcfStudent(MyStudent myStudent)
{
    this.Id= myStudent.Id;
    this.Name= myStudent.Name;
}

【讨论】：

我按照上述方法创建WcfStudent 对象的方式很好，或者有什么标准方法可以做到这一点？
我认为创建一个参数MyStudent的构造函数会更好： public WcfStudent(MyStudent myStudent){ //这里的对象之间的映射}
我应该把这个constructor.n客户端还是WCF服务端放在哪里？
Wcf 端。或者您可以在客户端创建，例如在 MyStudent 类方法中： ToWcfObject() 将执行相同的操作（返回 WcfStudent）

【解决方案2】：

您的 WCF 服务将包含 WcfStudent 类的定义，并将该类定义为数据协定（如果您不使用单独的 DTO）。

通过 WSDL 文件或 Visual Studio 界面在您的客户端项目中引用 WCF 服务，使您的客户端应用程序可以看到或了解该服务的公共类、接口等。这应该包括 WcfStudent 类。然后，您可以通过以下方式在您的代码中继续使用它：

MyWcfService.WcfStudent student = new MyWcfService.WcfStudent();
//assign values, etc

在您认为合适的情况下在您的应用程序中操作该学生对象，然后在您准备好持久化时调用您的 Web 服务。

client.InsertStudent (student);

【讨论】：

【解决方案3】：

您通常会使用数据合约而不是单个参数，因为这样您就可以轻松地对它们进行版本控制；并使用其他可选参数轻松扩展它们，并且仍然向后兼容。

我个人喜欢始终如一地遵循请求/响应模式：

public InsertStudentResponse InsertStudent(InsertStudentRequest request)  
{  
}

如果您不期望结果，那么响应类型当然可以是无效的。

请求对象只包含完成请求所需的内容。不多也不少。比如要改变一个学生的地址，不要在传递所有学生属性的同时调用ModifyStudent，而是调用MoveStudent，只传递新的地址信息；以便您明确定义业务运营。

关于你的操作的命名，InsertStudent 是一个类似 CRUD 的命名，而我更喜欢用商业术语来命名它们，比如 RegisterNewStudent 或其他东西。

也不要忘记错误契约：不要抛出异常，抛出错误。

【讨论】：