Блог

В моем решении у меня есть несколько проектов:

• Основной проект. Этот проект содержит все мои классы и интерфейсы
• Проект Winforms
• Веб-проект

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

 public IControl Create(Enum enum)
{
    switch(enum)
    {
      case "enum.A":
        return new CheckBoxControl();
      case "enum.B":
        return new RadioControl();
    }
}
  

Как вы могли догадаться, у меня есть пользовательские элементы управления. Все они наследуются от интерфейса (IControl). Но в этом случае CheckBoxControl и RadioControl являются элементами управления WinFroms.

Теперь эти элементы управления находятся в основном проекте. Я не хочу этого, потому что это базовая библиотека, и я хочу, чтобы эта библиотека была независимой от платформы.

Я хочу, чтобы элементы управления winforms были в проекте WinCore, а WebControls — в проекте WebCore. Проблема в том, как я могу вернуть правильные элементы управления из основного проекта?

И WebCore, и WinCore project нуждаются в ссылке на основной проект, потому что основной проект содержит мои объекты. Это означает, что я не могу установить ссылку из ядра веб- или wincore-проекта.

Как это решить?

Я бы сделал это:

• должна быть сборка, содержащая business .Core.

• .Shared должна быть сборкой, содержащей инфраструктуру, базовые классы и интерфейсы, не зависящие от платформы и технологии — так что это позволит вам ссылаться на нее в любом проекте, избегая нежелательных зависимостей -.

• .Web должна быть сборкой, содержащей веб-ориентированную функциональность

• должна быть сборка, содержащая только веб-формы и веб-элементы управления .Web.Forms.

• .Windows должна быть сборкой, поддерживающей функциональность, ориентированную на Windows.

• .Windows.Формы должны быть сборкой, содержащей только Windows Forms и элементы управления.

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

Кроме того, этого решения достаточно, чтобы позволить .Windows, .Windows.Ссылки на формы, .Web и .Web.Forms.Core и / или .Shared.

Обновить:

Это всего лишь предложение, но почему вы используете перечисление на своей фабрике? Вы могли бы это сделать:

 public TControl Create<TControl>() where TControl : IControl, new()
{
    IControl control = new TControl();

    // Control initialization work

    return control;
}
  

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

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

ОБНОВЛЕНИЕ 2:

Как инверсия управления может помочь вам в вашей проблеме?

Фактически, если вы зарегистрируете инверсию компонентов управления, вы получите доступ к ним по типу или по некоторому уникальному идентификатору.

Допустим, у вас есть IControl интерфейс (сервис), и оба реализуют WindowsTextBox и WebFormsTextBox IControl . В вашем файле конфигурации у вас будет два компонента, которые имеют одинаковый тип сервиса (интерфейс) и две разные реализации, и они будут помечены двумя разными идентификаторами:

• WindowsTextBox — это IControl с идентификатором WindowsTextBox.
• WebFormsTextBox — это IControl с идентификатором WebFormsTextBox.

Теперь у вас оба элемента управления зарегистрированы в вашем контейнере inversion of control, и вы можете использовать фабрику извлечения компонентов собственного API следующим образом:

• IoCFactory.GetComponents<IControl>() . Вам нужны все реализации IControl в текущей инверсии контейнера элемента управления — в вашем случае не рекомендуется! -.

• IoCFactory.GetComponent<IControl>("WindowsTextBox") . Вам нужна реализация IControl под названием «WindowsTextBox».

Во втором случае, на котором мы сейчас сосредоточимся, вы получаете объект, набранный как IControl, что означает, что вы можете получить доступ к его общим элементам (свойствам, методам, событиям …).

В чем смысл инверсии управления в вашей проблеме? Обратите внимание, что вы используете класс factory, который будет размещен в общей библиотеке, чтобы вы могли использовать его где угодно, и то же самое для интерфейса IControl.

Верно, я думаю, вам нужны конкретные экземпляры управления. Вы можете сделать две вещи:

• Просто поиграйте с экземплярами IControl и где угодно, в логике, зависящей от конкретной технологии, приведите его к конкретному типу — например, WindowsTextBox — и продолжайте.

• Создайте как можно больше интерфейсов, которые конкретизируют больше IControl, чтобы некоторая логика могла получить доступ к некоторым свойствам и методам, которые ближе к конкретному набору функций управления. Примером этого может быть интерфейс ITextBox, и получить любую инверсию управляющего компонента с помощью этого более конкретного интерфейса таким же образом, как я объяснил выше.

Я полагаю, что дал достаточно подсказок, чтобы получить представление о том, как структура моего решения и организация сборки, плюс инверсия управления, могут дать вам такую технологическую независимость, что вы смотрите между слоями вашего проекта и внутри них ! 😉

Добавьте Controlmanager в ядро с помощью метода RegisterControls. Webcore вызывает Controlmanager.Метод RegisterControls. Основное приложение взаимодействует только с core

Вы должны использовать другую фабрику в проекте WinForms и в веб-проекте. Создайте IControlFactory интерфейс, который реализован на обеих фабриках, и создайте экземпляр фабрики соответствующего типа в каждом проекте.