Как организовать правильную архитектуру с WCF-сервисом в трехзвенном проекте?

Question

[Юрий Щеглов]

Начал изучать WCF. Для своего тестового проекта решил сделать трехзвенный проект: 1) библиотека классов со всей бизнес-логикой и работой с БД на LinqToSql; 2) Библиотека службы WCF; 3) клиент ASP.NET MVC.
Собственно загвоздка возникла в том, как лучше всего организовать связь LinqToSql - WCF.
На данный момент интерфейсы моих LinqToSql-моделей:

interface IVisitor
    {
        DateTime DateOfBirth { get; set; }
        bool Gender { get; set; }
        string Name { get; set; }
        string Surname { get; set; }
        System.Data.Linq.EntitySet<Visit> Visit { get; set; }
    }

interface IVisit
    {
        DateTime DateVisit { get; set; }
        long IdVisitor { get; set; }
        Visitor Visitor { get; set; }
    }

как лучше будет эти классы перенести в WCF-проект и объявить [DataContract]-ами? Проставить аттрибуты прямо в проекте бизнес-логики будет плохим тоном, тем более, что придется лезть в дизайнер dbml.
Но будет ли хорошо по этим интерфейсам в проекте wcf-службы реализовать классы VisitorDataContract, VisitDataContract и в реализации службы приводить объект модели в объект этого класса? По сути же будет дублирование кода.

Answer 1

[Anatoliy Mikhailov]

Лучше сделать отдельные классы с теми же полями что и в моделях linq2sql а внутри реализации сервиса из контракта данных копировать поля в соответствующую модель например через AutoMapper.

public class MyService{
public IEnuberable<SVisit > GetAllVisitors(){
return dc.Visits.ToList().Select(Mapper.Map<SVisit>);
}
}