在面向服务的体系结构中为服务调用定义方法签名的最佳实践是什么? [英] What is the best practice to define method signature in Service oriented architecture for service call?

问题描述

在面向服务的架构中开发应用程序时定义服务调用原型/签名的最佳实践是什么.

What is the best practice to define service call prototype/signature while developing application in service oriented architecture.

例如，我想创建服务调用来发送电子邮件.

For Example I want to create Service call to send email.

假设我的域层中有以下对象

Let say I have following object in my domain layer

 [datacontract]
public class Email
{
      public string To { get; set; }
      public string From { get; set; }
      public string Message { get; set; }
      public string Subject { get; set; }

      //I am not going to use this properties in send email method
      public string OtherProp1 {get; set;}
      public string OtherProp2 {get; set;}
      public string OtherProp3 {get; set;}

  }

我应该像这样创建服务方法签名吗

Should I create Service method signature like

   public bool SendEmail(string from,string to, string subject,string message){//My Logic}}

或

   public bool SendEmail(Email myEmail){//My Logic}

我倾向于第一个选项.(话虽如此，我知道对象是否复杂而不是传递整个对象本身.)

I am leaning toward first option.(Having said that I know if object is way to complex than it make sense to pass whole object itself.)

推荐答案

不幸的是，在这种情况下，第二个选项不太清楚，这是因为您的 Email class.

Unfortunately, second option is less clear in this case and this is because of your Email class.

假设我要调用您的方法.你让我传递一个 Email 类的实例.我去类合同，找到7个属性.

Suppose I am to call your method. You make me pass an instance of the Email class. I go to the class contract and find 7 properties.

而且，我怎么知道哪些参数是强制性的，哪些是可选的?从文档?如果我必须查阅文档以正确使用 API，这不是最干净的设计.

And, how am I supposed to know which parameters are mandatory and which are optional? From the docs? Not a cleanest design if I have to consult the docs to make proper use of the API.

我宁愿重构您的 Email 类以将其称为 EmailRequest 并删除所有这些可选参数，然后如果您需要使用它，我将创建另一个类 EmailResponse作为服务的回报价值.

I would rather refactor your Email class to call it EmailRequest with all these optional parameters removed and then I would create yet another class EmailResponse if you ever need to use it as a return value of a service.

这篇关于在面向服务的体系结构中为服务调用定义方法签名的最佳实践是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！