Разрешение на высокий уровень вариаций в действиях и представлениях и моделях

Я разрабатываю систему управления продуктом. Мне интересно, как лучше всего обрабатывать большое количество вариаций в каждом Action/View в моем приложении. Приложение обрабатывает 20 категорий и 12 целевых рынков, каждый из которых влияет на данные, которые необходимо собирать для каждого продукта. Например, действие "QuickAdd" включает в себя основные данные, такие как имя продукта и SKU, а также несколько других ключевых элементов информации, основанных на комбо категории и целевом рынке, на которые добавляется продукт (примеры ниже). Категория и целевой рынок не являются настраиваемыми атрибутами продукта, пользователь, использующий систему, может работать только под конкретным комбо, например Toys/USA. Причиной упоминания этого является то, что я не могу создать форму для разделов атрибутов для каждой группы Category/Market, она должна работать так же, как форма предназначена только для этой категории/рынка - пользователь не знает других комбо.

Некоторые примеры, чтобы надеяться прояснить возможные ситуации:

Если я добавляю продукт в категорию Игрушки с целевым рынком США Мне нужно просить "возрастный диапазон" и "сделал он проходит проверку безопасности".

Если я добавляю продукт в категорию Игрушки с целевым рынком Мексика, я просто нужно спросить "Возрастной диапазон".

Если я добавляю продукт к категория Одежда с целью Рынок США Мне нужно попросить "Стиль" и "Материал"

Если я добавляю продукт к категория Одежда с целью Рынок Канады Мне нужно попросить "Стиль" и "Материал" и "Цена США"

У нас есть 20 категорий и 12 целевых Рынки, плюс 10 форм, которые нужно вести себя таким образом, поэтому в теории существует 2400 различных Действия/Просмотров/Модели

Итак, вопрос в ASP.NET MVC - как лучше всего обработать отображение всех этих динамических форм и обработку вариаций данных, которые отправляются в действие?

ИЗМЕНИТЬ
Прояснение того, как определяются атрибуты продукта: они основаны на иерархии продукта, принадлежащего категории на рынке. Например, это не дополнение всех атрибутов Toy и атрибутов США, о которых мы просим, ​​это атрибуты продукта, продаваемого на рынке США. Игрушка, продаваемая в США, нуждается в информации об инспекции безопасности, но Одежда в США этого не делает. Игрушка в Мексике также не нуждается в информации об инспекции безопасности, так что атрибут не присущ всем Игрушки или всем продуктам США, а скорее тот факт, что это комбинация как категории, так и рынка.

Ответ 1

Закончено с использованием довольно стандартной реализации EAV

Ответ 2

Я бы создал некоторые модели доменов для типов атрибутов.

public enum AttributeTypeEnum
{
    Currency,
    Range,
    List,
    Number,
    Text,
    Boolean
}

public interface class IAttribute
{
    int Id { get; set; }
    string Name { get; set; } 
    AttributeTypeEnum AttType { get; set; }
}

public abstract class BaseAttribute
{
    int Id { get;set;}
    string Name { get;set;}
    AttributeTypeEnum AttType { get; set; }
}

public class RangeAttribute<T> : BaseAttribute
{
   T StartValue { get;set; }
   T EndValue { get; set; }
}

Затем привяжите каждый атрибут к одной или нескольким категориям

public class CategoryAttribute
{
    int Id { get; set; }
    IAttribute Attribute { get; set; }
}

Затем вы можете иметь список атрибутов для каждой категории

public class CategoryAttributeService()
{
    public IList<CategoryAttributes> GetAttributes(int CategoryId)
    {
        return new IList<CategoryAttributes>();
    }
}

Затем ваш контроллер может вернуть список этих атрибутов в Model ViewData.Model.

// controller action
public class CategoryAttributeController : Controller
{
    public ActionResult CategoryAttributes(int categoryId)
    {
        CategoryAttributeService cas = new CategoryAttributeServices();
        ViewData.Model = new CategoryAttributeViewData(categoryId)
        {
            Attributes = cas.GetAttributes(categoryId);
        };
        return View();
    }
}

и пусть ваше представление обрабатывает тип каждого элемента и изменяет элементы управления/отображения каждого элемента соответственно, т.е. (диапазон с начальным и конечным значением) булев будет иметь флажок, материал может быть списком и т.д. у вас есть несколько вариантов того, как обрабатывать рендеринг, вы можете создать отдельный .ascx-элемент управления для каждого типа атрибута для создания элементов управления формы или, как показано ниже, создать html-помощник

<%@ Page Title="" Language="C#" Inherits="ViewPage<CategoryAttributeViewData>" %>

<% foreach(CategoryAttribute attribute in ViewData.Model.Attributes) { %>
<%= Html.RenderAttribute(attribute) %>
<% } %>

и вспомогательный метод, например

public static string RenderAttribute(this HtmlHelper, ICategoryAttribute att)
{
    StringWriter stringWriter = new StringWriter();
    using (HtmlTextWriter writer = new HtmlTextWriter(stringWriter))
    {
        switch(att.AttributeType)
        {
            case AttributeDataType.Boolean:
                CreateCheckBox(writer, att);
                break;
            case AttributeDataType.List:
                CreateListBox(writer, att);
                break;
            // Other types                
        }
    }
    stringWriter.ToString();
}

РЕДАКТОР: Я как бы отделил Рынки от вышеописанного, поэтому, если я это правильно понимаю, у каждого рынка есть несколько категорий (один на многие). Скажите США и Одежда. Категория Одежда может появляться на многих рынках. Каждая категория имеет ряд атрибутов (один для многих) (Одежда: цвет, размер), и каждый атрибут может иметь много рынков (от одного до многих)

  • Список рынков
  • Список категорий
  • Список MarketCategories
  • Список атрибутов CategoryAttributes
  • Список атрибутов
  • Список атрибутных маркеров

Рынки > MarketCategories > CategoryAttributes > Атрибуты > АтрибутMarkets

Правильно ли это?

Mac.

Ответ 3

Для каждого объекта модели модели создайте представление модели, которое фильтрует свойства в соответствии с текущим рынком,
возможно создать словарь нефильтрованных свойств "на лету"
или сигнализировать вид другим способом, какие свойства игнорировать/не игнорировать.
- Если фильтрация на одно свойство слишком велика, вы можете использовать отдельный просмотр модели на рынке (используя словарь).

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

Ответ 4

Настройте таблицу в своей базе данных, которая выглядит примерно так:

Category nvarchar(*)
Market nvarchar(*)
AttributeName nvarchar(*)
AttributeType nvarchar(*)

Затем сохраните каждую комбинацию атрибутов, которые вам нужны в этой таблице (очевидно, что некоторые рефакторинги могут быть выполнены, например, иметь таблицу "Атрибуты", которая хранит, требуется ли атрибут для быстрой вставки и разрешает Категорию/Рынок комбо для совместного использования атрибутов).

Затем, на ваш взгляд, прочитайте комманду User Category and Market и динамически создайте форму:

В вашей Page.Load для формы создайте экземпляры форм, которые вам нужны, дайте им значащие идентификаторы, затем в вашем обработчике обратной связи прочитайте все данные из объекта Request.Form.

Краткий пример:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
    Dim stuff As New System.Web.UI.WebControls.TextBox()
    stuff.ID = "WOW64"
    Page.Form.Controls.Add(stuff)
End Sub

Protected Sub Submit_Click(ByVal sender As Object, ByVal e As EventArgs)
    Dim str As String = Request.Form("WOW64")
    str = str ' do something with the string'
End Sub