Рекомендуемая структура для структуры сущности для CRUD DAL для WCF

Question

Мне нужно реализовать бэк-офисный уровень для приложения.Он должен будет реализовать доступ к данным через EF4 и предоставить доступ к данным как CRUD через службы WCF.Использование службы данных WCF не вариант, потому что требования представляют конечную точку службы TCP.

Я вижу, что EF в Vs 2010 поставляется с тремя шаблонами генератора кода для EF:

1. DbContext генератор, генерирует контекст, полученный из DbContext и классов сущностей как очень простые POCO без дополнительного кода;

   public partial class MyEntities : DbContext
   {...}
   

   И классы сущностей

   ....
   public int EmailAddressLocatorID { get; set; }
   ....
   public virtual Address Address { get; set; }
   ....
   public virtual ICollection<HouseholdGuest> HouseholdGuests { get; set; }
   

2. EntityObject генератор

3. Само отслеживающийся генератор сущностей, который генерирует контекст, полученный из ObjectContext и сущностей в виде классов POCO, реализующих IObjectWithChangeTracker иINotifyPropertyChanged, и вспомогательный класс ObjectChangeTracker

И я нашел еще один в Интернете, генератор сущностей POCO, который генерирует контекст на основе ObjectGenerator и классы сущностей как POCO сдополнительный код для отслеживания навигационных свойств, как показано ниже:

    public virtual ICollection<Guest> GuestsAddress
    {
        get
        {
            if (_guestsAddress == null)
            {
                var newCollection = new FixupCollection<Guest>();
                newCollection.CollectionChanged += FixupGuestsAddress;
                _guestsAddress = newCollection;
            }
            return _guestsAddress;
        }
        set
        {
            if (!ReferenceEquals(_guestsAddress, value))
            {
                var previousValue = _guestsAddress as FixupCollection<Guest>;
                if (previousValue != null)
                {
                    previousValue.CollectionChanged -= FixupGuestsAddress;
                }
                _guestsAddress = value;
                var newValue = value as FixupCollection<Guest>;
                if (newValue != null)
                {
                    newValue.CollectionChanged += FixupGuestsAddress;
                }
            }
        }
    }
    private ICollection<Guest> _guestsAddress; 

, где FixupCollection представляет собой простое усовершенствование ObservableCollection, реализующее ClearItems и InsertItem,, как показано ниже

public class FixupCollection<T> : ObservableCollection<T>
{
    protected override void ClearItems()
    {
        new List<T>(this).ForEach(t => Remove(t));
    }

    protected override void InsertItem(int index, T item)
    {
        if (!this.Contains(item))
        {
            base.InsertItem(index, item);
        }
    }
} 

Iхотел бы спросить уr посоветуйте, какой из них будет более подходящим для использования для реализации CRUD через службу WCF, и некоторые рекомендации по передовым методам реализации этого.

Спасибо

Answer 1

1. Это, вероятно, лучший подход из тех, что вы упомянули, но он потребует самых больших усилий. Прежде всего вам нужно будет сделать ваши сущности сериализуемыми с помощью WCF = вам придется изменить генератор для использования атрибутов DataContract(IsReference = true) и DataMember, потому что в противном случае вы получите исключение циклической ссылки при сериализации графа объекта (сущности с ее отношениями, где оба принципала и зависимые имеют свойство навигации друг к другу). При использовании графов объектов вам также придется самостоятельно отслеживать изменения или объединять данные, поскольку вы не будете знать об изменениях, внесенных на клиенте . Если вы не планируете передавать графы объектов, а только отдельные объекты или список одних и тех же объектов, с этим подходом все будет в порядке.
2. EntityObject специфичен для Entity Framework и показывать его клиентам - плохая идея. По умолчанию он сериализуется WCF, но также передает специфичную для EF информацию, такую ​​как EntityKey. Суть службы должна заключаться в том, чтобы скрыть свою внутреннюю реализацию, и разоблачение сущностей на основе EntityObject является нарушением этого правила. Это также не решает проблему отслеживания изменений.
3. STE разработаны для сценария , в котором вы хотите узнать об изменениях в графах объектов , внесенных на клиентах, но они не являются серебряной пулей. Сервисы и клиенты должны делиться только договором, описывающим обмен сообщениями. STE нарушают это правило, потому что они содержат логику, и клиент должен знать и использовать эту логику. STE основаны на совместном использовании сборки сущностей между службой и всеми клиентами = клиенты должны быть .NET-приложением или такая же логика должна быть переопределена на платформе, отличной от .NET. Они также всегда передают весь граф объектов - если вы загрузите 100 объектов в графе, отправьте их обратно клиенту, и клиент внесет изменения в один объект в графе, по умолчанию все 100 объектов будут отправлены обратно в сервис.
4. Генератор POCO обычно такой же, как и первый подход. Он просто использует API ObjectContext вместо API DbContext. Методы исправления зависят от конкретной службы, и клиент не узнает о них.

Последний подход заключается в использовании пользовательских не сущностных классов (DTOs = объекты передачи данных) и скрытии преобразования между DTO и сущностями в вашем сервисе. Это позволит вам создавать более сложный и подходящий набор объектов, но также сделает ваше приложение более сложным и усложнит разработку. Это также будет вариант в случае внедрения вашего собственного отслеживания изменений.