Правильно ли использовать МОК для расширения моих сущностей или модели домена?

Question

Я наткнулся на дилемму, которую, я думаю, стоит обсудить здесь.

У меня есть набор объектов домена (вы также можете назвать их сущностями, если хотите), которые получают некоторые данные от отдельного DAL, который разрешается с помощью МОК.

Я думал о том, чтобы сделать мою систему очень распространенной, и я бродил, если это правильно, чтобы также разрешать эти сущности МОК.

Позвольте мне представить тупой пример.

Допустим, у меня есть веб -сайт, для которого у меня есть следующий интерфейс:

public interface IArticleData
{
    int ID { get; }
    string Text { get; set; }
}

Концепция такова, что дал реализует такие интерфейсы, а также общий IDataProvider<TData> Inteface, после чего DAL становится легко заменяем. И есть следующий класс, который использует его:

public class Article
{
    private IArticleData Data { get; set; }

    public int ID
    {
        get { return Data.ID; }
    }

    public int Text
    {
        get { return Data.Text; }
        set { Data.Text = value; }
    }

    private Article(IArticleData data)
    {
        Data = data;
    }

    public static FindByID(int id)
    {
        IDataProvider<IArticleData> provider = IoC.Resolve<IDataProvider<IArticleData>>();
        return new Article(provider.FindByID(id));
    }
}

Это делает всю систему независимой от фактической реализации DAL (которая будет в примере, IDataProvider<IArticleData>).

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

public interface IArticle
{
    int ID { get; }
    string Text { get; set; }
}

public class Article : IArticle
{
    ...
}

И затем я удаляю все зависимости в класс статьи и начинаю разрешать его как переходную компонент Iarticle с МОК.

Например, в замке: <component id="ArticleEntity" service="IArticle" type="Article" lifestyle="transient" />

После этого, если мне придется расширить это, это было бы так просто:

public class MyArticle : Article
{
   public string MyProperty { ..... }
}

И все, что мне нужно сделать, это изменить конфигурацию на это: <component id="ArticleEntity" service="IArticle" type="Article" lifestyle="transient" />

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

Кстати, это кажется хорошим решением для философии «разделения проблем».

У меня вопрос, это правильно? После некоторого серьезного мышления я не мог понять, что можно найти лучшим способом сделать это. Я также рассматривал MEF, но, похоже, он ориентирован на создание плагинов, но не на замену и не расширяю уже полные части такой системы.

Я прочитал много вопросов (а также других источников) по этой теме, наиболее заметными являются:Как мне обрабатывать свои объекты сущности/домена с использованием инъекции IOC/зависимости? а такжеМОК, куда вы положили контейнер?

И я также боюсь, что попадаю на проблемы, описанные на следующих страницах:http://martinfowler.com/bliki/anemicdomainmodel.html а такжеhttp://hendryluk.wordpress.com/2008/05/10/should-domain-entity-be-managed-by-ioc/

И еще одна вещь: это увеличит проверку всей системы, не так ли?

Что вы думаете?

Изменить: Другой вариант - создать заводской шаблон для этих сущностей, но IoC.Resolve<IArticle> намного проще, чем IoC.Resolve<IArticleFactory>().CreateInstance()

Answer 1

Я думаю, что вы можете переоценить вещи. Не могли бы вы когда -нибудь заменить статью другим типом, который реализовал Iarticle?

Контейнеры МОК лучше всего используются, когда у вас есть компонент более высокого уровня, который зависит от компонента более низкого уровня, и вы хотите, чтобы компонент более высокого уровня зависел от абстракции этого компонента, поскольку компонент нижнего уровня выполняет некоторые операции внутри. Трудно проверить компонент более высокого уровня, например, доступ к базе данных. Или компонент нижнего уровня может представлять конкретную стратегию в вашем приложении, которая может быть взаимозаменяемо с другими стратегиями, например, шлюз базы данных, который абстрагирует детали работы с API базы данных, специфичных для поставщика.

Поскольку статья-это простой класс в стиле Poco, маловероятно, что вы получите какие-либо преимущества, создавая его экземпляры, хотя IOC-контейнер.