Проектирование наследования классов моего пользовательского элемента управления

Question

Я создаю пару различных пользовательских элементов управления, каждый из которых реализует различные базовые элементы управления, но все они будут получать некоторые общие свойства и функциональные возможности, добавленные к ним. Поэтому я хотел поместить эти общие свойства (с их общими получателями и установщиками) и дублирование функциональности в абстрактный класс. Но я с трудом нахожусь в голове, как спроектировать элементы управления и их основы, чтобы обеспечить реализацию как моего абстрактного класса, так и базового веб-элемента управления, над которым я работаю. Кто-нибудь может мне помочь?

Некоторые элементы управления, которые я строю

public class AssetDataStringControl : TextBox
public class AssetDataIntegerControl : TextBox
public class AssetDataUrlControl : CompositeControl
public class AssetDataListBoxControl : ListBox
public class AssetDataDropDownControl : DropDownList

Мой абстрактный класс

public abstract class AssetDataInputControlBase<T> : Control, 
    IAssetDataInputControl<T>
{
    protected virtual int AssetId
    {
        get
        {
            object o = ViewState["AssetId"];
            return o == null ? 0 : (int)o;
        }
        set { ViewState["AssetId"] = value; }
    }

    protected virtual AssetStructureField StructureField
    {
        get
        {
            object o = ViewState["StructureField"];
            return o == null ? null : (AssetStructureField)o;
        }
        set { ViewState["StructureField"] = value; }
    }

    public abstract T DataField { get; set; }
}

Answer 1

Забудьте о abstract.Мне кажется, что цепочка наследования веб-элемента управления .NET функционирует, а не навязывает тонны реализации плохим элементам управления "конечным продуктом".Я посмотрю, смогу ли я пойти с потоком на этом.И это подразумевает наследование от соответствующего класса, чтобы получить основу для построения (каламбур).

Похоже, вы хотите создать составные веб-элементы управления. Внимательно прочитайте документацию по System.Web.UI пространству имен.Рассмотрим наследование от System.Web.UI.CompositeControl.Это дает вам коллекцию дочерних элементов управления и некоторые встроенные рендеринга.И он реализует INamingContainer для управления уникальными идентификаторами дочерних элементов управления.

Просто подумайте, может быть, вы можете создать класс, который создает пользовательские композиции во время выполнения (вы можете сказать factory pattern?). Внимательно прочитайте документацию по System.Web.UI пространству имен. В любом случае, база уже знает, как визуализировать композит.Каждый подэлемент управления (текстовое поле, список и т. Д.) Знает, как визуализировать себя.На фабрике каждому субконтролю присваивается привязка данных.Затем внедряет их в ваш собственный конструктор (ы) CompositeControl.

Answer 2

Одно предложение: сделайте AssetDataInputControlBase как Canvas и поместите в него любой элемент управления, который вы хотите. Будучи холстом, он будет вести себя как контроль. Любые необходимые методы / свойства Control требуют добавления в ADICB методов, вызывающих методы Control. Если их много, эта идея не так хороша.

Еще одно предложение: ваши элементы управления могут реализовывать интерфейс, который имеет метод, который возвращает что-то вроде AssetDataInputControlBase, только в этом случае ADICB не будет реализовывать Control или что-то еще. Вместо этого он будет иметь только AssetID, AssetStructureField и DataField (и другие вещи, которые потребуются позже). Таким образом, ваши элементы управления (например, AssetDataStringControl) просто расширяют элемент управления (например, TextBox) и, кроме того, содержат ссылку на объект ADICB.

Это предполагает, что значения ADICB довольно независимы от элемента управления (скажем, TextBox). Если для метода get из StructureField требуются все виды информации из TextBox, и нужно получать ее по-разному, если вместо этого используется ListBox, все будет запутано, и вам нужно лучшее решение. Если не , ваши элементы управления - это просто расширения TextBox, ListBox и т. Д. С одной добавленной ссылкой на объект ADICB. Один класс ADICB, какой бы сложный он ни был написан, может использоваться всеми вашими элементами управления.

Это выглядит как хороший аргумент для множественного наследования.