Как построить интегрированную архитектуру в C #?

Question

У меня есть концепция для системы управления, которую я хотел бы построить. Отличительной чертой этой идеи является то, что я не собираюсь использовать подход «один размер подходит всем» или «один элемент управления, чтобы управлять ими всеми».

Например, Telerik делает очень хороший элемент управления Grid, как и ComponentOne, Xceed и т. Д. Однако все они являются гигантскими элементами управления с сотнями или тысячами методов и свойств, комплексными объектными моделями и т. Д. ... Все слишком часто эти сетки слишком излишни для того, что вам нужно, но вам все равно придется взяться за сложнейшую задачу изучения всей сетки, чтобы сделать что-то простое.

Моя концепция - это скорее "смешанный" подход. Где вы создаете очень простой элемент управления, а затем создаете функции, которые вы можете «добавить» в элемент управления а-ля-карт. Например, у вас есть простая сетка, и вы хотите добавить «секции» сетки с верхними и нижними колонтитулами для каждого.

Хорошо, так в чем же проблема? Традиционный способ сделать что-то подобное это через множественное наследование, которое C # не поддерживает. Даже если он это поддержал, я все еще придерживаюсь мнения, что MI добавляет больше проблем, чем решает.

Итак, я собираюсь узнать мнение о том, как подойти к этой проблеме. Будет ли MEF потенциальным решением?

EDIT:

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

Другим возможным вариантом может быть «Генератор управления», который генерирует сборку на основе выбранных элементов. Это кажется более сложным, но с T4 может быть управляемым.

Answer 1

Несколько вариантов

1. Рассмотрим шаблон Decorator; небольшие объекты, которые расширяют поведение довольно минималистского класса, который вы можете создать во время выполнения. Канонический пример в структуре Dotnet будет касаться потоков ввода-вывода (например, StreamReader / Writer, TextStreamReader / Writer, FileStreamReader / Writer); это довольно часто встречается и в OO UI Framework, с типичным примером, похожим на var window=new HorizontalScrollingWindowDecorator(new VerticalScrollingWindowDecorator(new Window));

2. Шаблоны State, Strategy, Command и Composite предлагают различные альтернативы для работы с композицией поведения, не требуя большого потока управления. Например, вы делегируете определенные типы поведения текущему состоянию вашего объекта (некоторые из ваших методов класса в основном вызывают методы текущего состояния объекта). Вы также можете делегировать поведение командным объектам или создавать сложные команды, используя составные команды. Одиночное наследование обычно побуждает вас отдавать предпочтение композиции объектов по сравнению с наследованием, и это все классические шаблоны для составления поведения, которые хорошо работают с одиночным наследованием.

3. Вы можете использовать делегаты для паттерна «дыра в середине», который является обычным в функциональном программировании, когда какой-то небольшой фрагмент поведения должен быть реализован конкретным экземпляром.

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

Answer 2

Лично я думаю, что множественное наследование было бы плохим способом реализовать этот вид дизайна в любом случае. Кажется, что множественное наследование - плохой дизайн в большинстве случаев. Наследование далеко от жесткой связи между компонентами.

Композиция гораздо более гибкая, и в этом случае MEF будет очень хорошей отправной точкой для этого.

Базовый класс для ваших элементов управления будет контейнером поведения - по сути, контейнером MEF.

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

Answer 3

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

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

---

Что касается MEF, MEF покупает вам обнаружение и внедрение кода расширения. Это ценно, но напрямую не решает проблему, которую вы описали. Ваша проблема связана не столько с обнаружением кода, сколько с механизмом компоновки этого кода для создания согласованного общего элемента управления. MEF может быть полезен для выполнения склеивания, но это относительно небольшая часть проблемы.

Answer 4

Я хотел бы попытаться ответить, не комментируя, стоит ли решать эту проблему.

Я не пробовал это для компонента, но теоретически есть Шаблон декоратора : вы можете добавить плагины во время выполнения для перехвата ввода (клавиатуры и мыши) и вывода (экрана) элемента управления.

Answer 5

Если вы заинтересованы в фреймворке, в котором уже есть миксины для справки, взгляните на фреймворк re-motion (https://www.re -motion.org /). Удивительно, как легко могут быть реализованы миксины в этом фреймворке,

Ниже приведено справочное приложение на уровне «Hello World».

С помощью сборок, загруженных с веб-сайта, создайте библиотеку классов и консольное приложение в VS2010, в обоих проектах добавьте ссылки на сборки remotion.dll и remotion.interfaces.dll.

using System;

namespace Domain
{
  public class Person
  {
    public Person()
    {
    }
    public Person(Person person)
    {
      FirstName = person.FirstName;
      LastName = person.LastName;
      BirthDay = person.BirthDay;
    }

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime BirthDay { get; set; }
  }
}



using System;
using Remotion.Mixins;

namespace Domain
{
  public interface IEmployeeMixin
  {
    int Salary { get; set; }
    DateTime? HireDate { get; set; }
  }

  [Extends(typeof(Person))]
  public class EmployeeMixin : IEmployeeMixin
  {
    public int Salary { get; set;  }
    public DateTime? HireDate { get; set;}
    public EmployeeMixin()
    {
      // set default values
      Salary = 1000;
      HireDate = DateTime.Now;
    }
  }
}



using Domain;
using Remotion.Reflection;
using Remotion.Mixins;

namespace ConsoleApp
{
  class Program
  {
    static void Main(string[] args)
    {
      Person p = new Person();
      p.FirstName = "John";
      p.LastName = "Doe";

      var employee = (IEmployeeMixin)ObjectFactory.Create<Person>(ParamList.Create(p));

      System.Console.WriteLine("Fullname: {0}", ((Person)employee).FirstName + " " + ((Person)employee).LastName);
      System.Console.WriteLine("Salary: {0}", employee.Salary);

      System.Console.ReadKey();
    }
  }
}

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

Stefan

Answer 6

Вы хотите создать фреймворк типа Add-In? Я бы определенно указал вам на Managed Extensibility Framework. Может использоваться в .Net 4.0 с WinForms или WPF.