Я строю совершенно новую систему с использованием 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 (строка toAccount). Это становится нашим знакомым и эффективным OOAD. Это включает маппер для отображения между классами домена AccountSummary DTO и FixedAccount / SavingsAccount.

2)Подход 2: Без использования картографического слоя перевода.

Вопросов

1) Предположим, я использую подход 1. Существует ли какая-либо статья / учебное пособие, в котором объясняется, как сопоставить AccountSummary DTO с классами домена FixedAccount / SavingsAccount на основе значения AccountType в DTO (условное сопоставление)?

2) Как мне решить задачу в подходе 2?

ЧТЕНИЕ: -

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

Доступ к данным архитектуры SOA

Проектирование услуг и операций в WCF

Данные WCF Контракт и Справочные данные?

Когда логика принадлежит бизнес-объекту / сущности и когда она принадлежит сервису?