Моделирование домена - Реализовать интерфейс свойств или POCO?

Question

Я создаю прототип инструмента, который будет импортировать файлы через API-интерфейс SOAP в веб-приложение и смоделировал то, что я пытаюсь импортировать через интерфейсы C #, чтобы я мог обернуть данные модели веб-приложения в то, с чем я могу иметь дело.

public interface IBankAccount
{
    string AccountNumber { get; set; }
    ICurrency Currency { get; set; }
    IEntity Entity { get; set; }
    BankAccountType Type { get; set; }
}

internal class BankAccount
{
    private readonly SomeExternalImplementation bankAccount;

    BankAccount(SomeExternalImplementation bankAccount)
    {
        this.bankAccount = bankAccount;
    }

    // Property implementations
}

Затем у меня есть репозиторий, который возвращает коллекции IBankAccount или чего-либо еще и фабричный класс для создания BankAccounts для меня, если они мне понадобятся.

Мой вопрос заключается в следующем:причинить мне много боли в будущем, и было бы лучше создать POCO?Я хочу поместить все это в отдельную сборку и полностью разделить доступ к данным и бизнес-логику, просто потому, что здесь я имею дело с движущейся целью относительно того, где данные будут храниться в сети.

Answer 1

Это именно тот подход, который я использую, и у меня никогда не было проблем с ним.В моем проекте все, что выходит из уровня доступа к данным, абстрагируется как интерфейс (я называю их контрактами на передачу данных).В моей доменной модели у меня есть статические методы для создания бизнес-сущностей из этих объектов передачи данных.

interface IFooData
{
    int FooId { get; set; }
}

public class FooEntity
{
    static public FooEntity FromDataTransport(IFooData data)
    {
        return new FooEntity(data.FooId, ...);
    }
}

Это очень удобно, когда ваши доменные модели собирают свои данные из нескольких контрактов данных:

public class CompositeEntity
{
    static public CompositeEntity FromDataTransport(IFooData fooData, IBarData barData)
    {
        ...
    }
}

В отличие от вашего проекта, я не предоставляю фабрики для создания конкретных реализаций контрактов на передачу данных, а скорее предоставляю делегатов для записи значений и позволяю хранилищу беспокоиться о создании конкретных объектов

public class FooDataRepository
{
    public IFooData Insert(Action<IFooData> insertSequence)
    {
        var record = new ConcreteFoo();

        insertSequence.Invoke(record as IFooData);

        this.DataContext.Foos.InsertOnSubmit(record); // Assuming LinqSql in this case..

        return record as IFooData;
    }
}

использование:

IFooData newFoo = FooRepository.Insert(f =>
    {
        f.Name = "New Foo";
    });

Хотя, на мой взгляд, заводская реализация является столь же элегантным решением.Чтобы ответить на ваш вопрос, по моему опыту очень похожий подход, я никогда не сталкивался с какими-либо серьезными проблемами, и я думаю, что вы на правильном пути здесь:)