我建立使用WCF一个全新的系统。我将使用契约优先途径是基于面向服务的概念，要建立一个服务。我有一个返回用户的银行账户信息的服务操作。该帐户可以是类型FixedAccount或SavingsAccount。我有如下设计服务。

  [的ServiceContract]
接口IMyService
{
[OperationContract的]
AccountSummary AccountsForUser（用户用户）;
}


[DataContract]
类AccountSummary
{
 [数据成员]
 公共字符串账户号码{获取;集;}

 [数据成员]
 公共字符串AccountType {获取;集;}
}
 

这多是罚款。

现在，我需要开发该服务的业务领域。我能想到的两个选项（任何新的方法总是受欢迎的）

1）办法1 ：拿出一个BankAccount的基类。从它派生的专业类是FixedAccount和SavingsAccount。显示BankAccount将有一个方法，转移（字符串toAccount）。这将成为我们熟悉的＆放大器;有效的OOAD。这包括映射器AccountSummary DTO和FixedAccount / SavingsAccount域类之间的映射。

2）的办法2 ：不使用映射器转换层

问题

1）假设我使用的方法1.是否有任何文章/教程，介绍了如何根据DTO（有条件的映射）？

在AccountType值AccountSummary DTO映射到FixedAccount / SavingsAccount域类

2）如何实现任务的方法2？

阅读： -

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

SOA架构的数据访问

设计的WCF服务和运营

WCF数据合同和参考实体数据？

When没有逻辑，属于业务对象/实体，而当它属于一个服务？

解决方案

首先 - 你需要明白，如果你真的需要全面的SOA

SOA基本上意味着每一个操作正在经历的服务，去耦我们的系统与其他系统/秒。从另一个系统的一个组成部分。

- 在极少数情况下（在应用程序的增长额外的巨大）。

请问您的应用程序对话与任何其他应用程序？

如果没有，你只是建立整体的网站，释放你的头脑和削减了SOA bullcrap。否则，你将结束与无用的抽象层。

这就是你可以申请第二个方法，因为你不能完全脱钩的领域模型没有将其映射到别的东西的唯一途径。

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

  

有没有文章/教程，介绍了如何AccountSummary DTO映射到FixedAccount / SavingsAccount

映射本身并不复杂的想法。这里有一个简单的方法来映射对象：

 类AccountSummary {
  公共字符串InterestingThing {获得;组;}
  公共字符串AnotherThing {获得;组;}
}
类AccountSummaryMapper {
   公共静态地图（BankAccount的一个）{
    返回新AccountSummary {
        InterestingThing = a.SomethingSomething，
        AnotherThing = a.Something.Else.ToString（）
      };
   }
}
VAR accountSummary =
  AccountSummaryMapper.Map（myBankAccount）;
 

这似乎是无效的。对象到对象的映射器如 Automapper 可以提供帮助。通过教程，应该足以让你去。想法并不难 - 你创建的地图，告诉映射关于他们在应用程序启动，然后使用映射器通过给定的配置来映射你的对象

另外 - 想想映射方向。 Good面向对象的code 通常意味着你要么提出问题，或告诉对象的做的东西。对象不应该知道的其他对象的职责内部工作。

在比喻 - 它是坏的父母来完成他们的孩子的家庭作业，因为孩子会学不到任何东西，家长将不必要的工作所累。相反 - 家长应该强迫孩子工作，他自己

映射AccountSummary直接的BankAccount并重新设置它的状态是像做功课。不应该有这样的一个映射被需要。相反 - 告诉的BankAccount到BankAccount.DoHomework（铅笔，字帖，someStrongWords）

  

开拓业务领域

您不发展的业务领域。您开发领域模型这仅仅是一个反映业务领域，为解决特定的问题。

I am building a completely new system using WCF. I am going to use Contract-First Approach for a service which is to be built based on Service Oriented concepts. I have a service operation that returns a bank account details of a user. The account can be of type "FixedAccount" or "SavingsAccount". I have designed the service as follows.

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


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

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

This much is fine.

Now, I need to develop the business domain for this service. I can think of two options (any new approach is always welcome)

1) Approach 1: Come up with a BankAccount base class. The specialized classes derived from it are "FixedAccount" and "SavingsAccount". The BankAccount will have an method as Transfer(string toAccount). This becomes our familiar & effective OOAD. This involves mapper for mapping between AccountSummary DTO and FixedAccount/ SavingsAccount domain classes.

2) Approach 2: Without using mapper translation layer.

Questions

1) Suppose I am using approach 1. Is there any article/tutorial that explains how to map AccountSummary DTO to FixedAccount/ SavingsAccount domain classes based on the AccountType value in DTO (conditional mapping) ?

2) How do I achieve the task in approach 2 ?

READING:-

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

SOA architecture data access

Designing services and operations in WCF

WCF Data Contract and Reference Entity Data?

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

解决方案

First of all - you need to understand if you really need full-blown SOA.

SOA basically means that every operation is going through service that decouples our system from other system/s. In rare cases (in case application grows extra huge) - one part of system from another.

Will your application "talk" with any other application?

If not and you are just building monolith website, free your mind and cut that SOA bullcrap. Otherwise you will end up with useless abstraction layer.

That is the only way you can apply 2nd approach because you can't decouple domain model completely without mapping it to something else.

In case there really is a need for SOA - we must encapsulate, hide from outer world our domain model. That means - there must be some kind of mapping from our model to DTOs.

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

Mapping itself isn't complex idea. Here's one simple way to map objects:

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);

This might seem ineffective. Object-to-object mappers like Automapper can help. Go through tutorial, it should be good enough to get you going. Idea ain't hard - you create Maps, tell Mapper about them on application start and then use Mapper to Map your objects by given configuration.

Also - think about mapping direction. Good object oriented code usually means that you either ask questions or tell object to do stuff. Objects shouldn't know about inner workings of other object responsibilities.

In analogy - it is bad for parents to complete their child homework because child won't learn anything and parent will be burdened with unnecessary work. Instead - parent should force child to work on his own.

Mapping AccountSummary directly to BankAccount and re-setting its state is like doing homework. There shouldn't be need for such a mapping. Instead - tell BankAccount to BankAccount.DoHomework(pencil, copybook, someStrongWords).

develop the business domain

You do not develop business domain. You develop domain model which is just a reflection of business domain, made to solve particular problems.