Проблема с созданием репозитория в сущностях C # и ADO.NET

Question

Я создаю это приложение ночью после работы и уже неделю или две пытаюсь решить эту проблему.

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

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

Даже если пользователи не могли изменять поля, я хочу убедиться, что изменения схемы данных не создают проблем для текущих данных.

Чтобы построить схему, способную на все это, я сделал следующее:

DTYPE

• id
• тип данных

поле

• id fieldName

• fieldDataType (связанный внешним ключом с dtype)

DATASTORE

типа ol> id int

запись

Хорошо, схема очень денормализована, но с ней сложно работать в ASP.NET MVC.

Моя вторая попытка заключалась в создании класса с типизированными свойствами для хранения любого типа данных, в котором оказалась запись.

Пользовательский класс для уровня домена публичная запись { public List dataList = new List ();

    public entry(int id)
    {
        kleraDataContext s = new kleraDataContext();
        var dataSet = s.dataStores.Where(c => c.citationID == id);
        foreach (dataStore y in dataSet)
        {
            dataBlob tempd = new dataBlob();

            //We get the data type id
            var temp = s.fields.Where(c => c.id == y.fieldID).First();

            //Get the fieldname and store the data type id for later
            tempd.fieldname = temp.fieldName;
            tempd.dataType = temp.dtype.dataType;

            switch (tempd.dataType)
            {
                case "String":
                    tempd.dString = y.dataString;
                    break;
                case "Text":
                    tempd.dString = y.dataText;
                    break;
                default:
                    //Nothing
                    break;
            }

            this.dataList.Add(tempd);
        }
    }
}

    public class dataBlob
    {
        private string _dString;
        private DateTime _dDate;
        private int _dInt;
        private double _dDouble;
        private object _data;
        private string _fieldname;
        private string _dataType;

       public string dataType
        {
            get
            {
                return _dataType;
            }
            set
            {
                _dataType = value;
            }

        }

        public object data
        {
            get
            {
                return _data;
            }
        }

        public string dString
        {
            get
            {
                return _dString;
            }
            set
            {
                _dString = value;
                _data = value;
            }

        }

        public string fieldname
        {
            get
            {
                return _fieldname;
            }
            set
            {
                _fieldname = value;
            }
        }

        public DateTime dDate
        {
            get
            {
                return _dDate;
            }
            set
            {
                _dDate = value;
                _data = value;
            }

        }

        public double dDouble
        {
            get
            {
                return _dDouble;

            }
            set
            {
                _dDouble = value;
                _data = value;
            }

        }

        public int dInt
        {
            get
            {
                return _dInt;

            }
            set
            {
                _dInt = value;
                _data = value;
            }

        }
    }
}

Обратите внимание на несколько проблем с этим.

1. У меня проблемы с получением достаточно универсального свойства для хранения данных независимо от того, какой тип поля в физической структуре. В идеале, средство доступа к данным должно было бы просто получить любой тип данных.
2. У меня все еще нет достаточно хорошего способа обеспечить представления ASP.NET MVC достаточно последовательной моделью, чтобы код представления не выполнял синтаксический анализ. В идеале представление просто получило бы объект со списком полей и соответствующими им данными.
3. Относительно # 2, я не могу найти подходящий способ сохранения изменений. Написание запроса и его возвращение полей в представление может быть сделано. Поскольку каждое поле не является строго типизированным средством доступа, я не уверен, как сохранить изменение от представления к модели. Наивно, я думал о вставке ключа в скрытый промежуток и использовании объекта Dictionary в контроллере для отображения изменений / создания.

Мысли

Рон * * 1092

Answer 1

Хотя я не совсем уверен в вашей конечной цели, у меня может быть выбор для вас. Вам нужна высокодинамичная «сущность», которая позволит вашим пользователям создавать свои собственные структуры данных. Императивные языки, такие как C #, плохо подходят для таких вещей ... и даже с динамическим языком, я думаю, вы, скорее всего, столкнетесь с некоторыми трудностями. Тем не менее, XML является отличным способом представления динамических структур данных специальным способом, создаваемым во время выполнения.

Если вы используете SQL Server, я рекомендую вам создать более простой тип, как показано ниже, и сохранить его в таблице, которая использует тип данных «xml» для одного из столбцов:

public class DynamicEntity
{
    public int ID { get; set; }
    public string TypeName { get; set; }
    public XDocument DynamicContent { get; set; }
}

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

CREATE TABLE DynamicEntity
(
    ID int IDENTITY(1,1) NOT NULL,
    NAME varchar(50) NOT NULL,
    DynamicContent xml NULL
)

Учитывая возможности xml в SQL Server, вы все равно сможете запрашивать данные в этом столбце xml. Мало того, что если вы хотите, чтобы пользовательские структуры пользователей были проверены на соответствие схеме, вы также можете поместить эту схему в базу данных и «напечатать» свой столбец xml на этой схеме. Использование столбца XML в SQL Server сопутствует предостережениям, но это может быть простым решением вашей сложной проблемы.