.net - 契约优先 SOA : Designing Business Domain: WCF

Question

我正在使用 WCF 构建一个全新的系统。我将对基于面向服务概念构建的服务使用契约优先方法。我有一个返回用户银行帐户详细信息的服务操作。该帐户可以是“FixedAccount”或“SavingsAccount”类型。我设计的服务如下。

[ServiceContract]
interface IMyService
{
[OperationContract]
AccountSummary AccountsForUser(User user);
}


[DataContract]
class AccountSummary
{
 [DataMember]
 public string AccountNumber {get;set;}

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

这么多就好了。

现在，我需要为这项服务开发业务领域。我可以想到两种选择(任何新方法总是受欢迎的)

1) 方法 1:提出一个 BankAccount 基类。从它派生的专门类是“FixedAccount”和“SavingsAccount”。 BankAccount 将有一个方法作为 Transfer(string toAccount)。这成为我们熟悉且有效的 OOAD。这涉及用于在 AccountSummary DTO 和 FixedAccount/SavingsAccount 域类之间进行映射的映射器。

2) 方法 2:不使用 mapper 转换层。

问题

1) 假设我使用的是方法 1。是否有任何文章/教程解释如何根据 DTO 中的 AccountType 值将 AccountSummary DTO 映射到 FixedAccount/SavingsAccount 域类(条件映射)？

2) 如何完成方法 2 中的任务？

---

阅读:-

1. http://www.soapatterns.org/service_facade.php

2. SOA architecture data access

3. Designing services and operations in WCF

4. WCF Data Contract and Reference Entity Data?

5. When does logic belong in the Business Object/Entity, and when does it belong in a Service?

Answer 1

首先 - 您需要了解您是否真的需要成熟的 SOA。

SOA 基本上意味着每个操作都通过将我们的系统与其他系统分离的服务进行。在极少数情况下(如果应用程序变得非常庞大)- 系统的一部分来自另一部分。

您的应用程序会与任何其他应用程序“对话”吗？

如果不是，而您只是在构建单体网站，请解放您的思想并减少 SOA 废话。否则你最终会得到无用的抽象层。

这是您可以应用第二种方法的唯一方法，因为如果不将域模型映射到其他东西，您就无法完全解耦域模型。

---

如果真的需要 SOA - 我们必须封装，从外部世界隐藏我们的域模型。这意味着 - 必须有某种从我们的模型到 DTO 的映射。

Is there any article/tutorial that explains how to map AccountSummary DTO to FixedAccount/ SavingsAccount

映射本身并不是一个复杂的概念。这是映射对象的一种简单方法:

class AccountSummary{
  public string InterestingThing {get; set;}
  public string AnotherThing {get; set;}
}
class AccountSummaryMapper{
   public static Map(BankAccount a){
    return new AccountSummary{
        InterestingThing=a.SomethingSomething,
        AnotherThing=a.Something.Else.ToString()
      };
   }
}
var accountSummary=
  AccountSummaryMapper.Map(myBankAccount);

这似乎无效。对象到对象映射器，如 Automapper可以帮助。通过教程，它应该足以让你开始。想法并不难 - 您创建 map ，在应用程序启动时将它们告知 Mapper，然后使用 Mapper 通过给定配置映射您的对象。

---

另外 - 考虑映射方向。 Good object oriented code通常意味着您要么提出问题，要么告诉对象做事情。对象不应该知道其他对象职责的内部工作。

打个比方 - parent 完成 child 的家庭作业是不好的，因为 child 不会学到任何东西， parent 会承担不必要的工作。相反 - parent 应该强制 child 自己工作。

将 AccountSummary 直接映射到 BankAccount 并重新设置其状态就像做作业一样。不需要这样的映射。相反 - 将 BankAccount 告诉 BankAccount.DoHomework(pencil, copybook, someStrongWords)。

---

develop the business domain

您不开发业务领域。您开发的领域模型只是业务领域的反射(reflect)，旨在解决特定问题。