IoC и абстрактные классы

Question

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

Проект A:

public interface ISentimentEngine
{
    SentimentEngineServices SentimentEngineProvider {get;}
    ISentimentEngineResult AnalyseSentiment(ISentimentRequest request);
}

У меня также есть абстрактный класс, который будет содержать некоторые общие функциональные возможности для моих конкретных реализаций реальных служб:

Проект B:

public abstract class SentimentEngineBase
{
    protected abstract int MaximumRequests { get; }
    protected SentimentEngineBase(string configurationXml)
    {

    }
    protected abstract SentimentEngineServices SentimentEngineProvider { get; }
    protected abstract string SentimentEngineName { get; }

    protected abstract void ProcessClientConfiguration(string configuration);
    protected abstract void GetDefaultConfiguration();
}

Вышеупомянутый абстрактный класс находится в том же проекте, что и другие объекты, такие как реализации ответа и запроса, а все интерфейсы находятся в отдельном проекте контракта (A), вреализация шаблона лестницы.

Затем отдельные реализации находятся в следующих проектах:

Проект C:

public class MicrosoftAzureTextAnalyticsSentiment : SentimentEngineBase, ISentimentEngine
{

Мне не нравится то, чтоКонкретная реализация службы должна зависеть от базового абстрактного класса (Project B), а также от интерфейса (Project A), а также от всех реализаций, которые я создаю для каждого поставщика услуг, например, Microsoft Azure Text Analytics, Google Cloud Natural.Язык, Amazon Comprehend и т. Д., Которые будут отображаться отдельно.

Я хочу использовать IoCи вводить интерфейсы в конструкторы различных объектов:

Опции:

1. Это все хорошо, это не имеет значения, не беспокойтесь об этом и двигайтесь дальше !!!
2. Разделите базовый класс на другой проект, проект D. Отсоедините его от других классов.
3. Используйте только интерфейсы, перемещая некоторые абстрактные методы в интерфейс;(но мне действительно не нравится, что они имеют общедоступные свойства и вынуждены все время выполнять работу по ногам).
4. Есть ли другой подход.

Извините, это, вероятно,ребята, я, наверное, упускаю что-то очевидное, но я не вижу дерева для деревьев.

Спасибо,

Stu.

Answer 1

Я думаю, что все в порядке.Да, проект C, реализующий интерфейс, будет зависеть от проектов A и B, как и проект C 'для Google Cloud Natural Language или C "для Amazon Comprehend. Но это другой проект E с этим SentimentEngineConsumer

class SentimentEngineConsumer
{
    ISentimentEngine _engine;
    public SentimentEngineConsumer(ISentimentEngine engine)
    {
        _engine = engine;
    }

    ...

}

только хочет использовать интерфейс, не будет нуждаться в проектах B, C, C ', C ", ... Он может просто использовать проект A. Его можно оставить модулю внедрения зависимостей, чтобы затем связать либо C, C', либоC "для проекта E.