1

私は仕事の後の夜にこのアプリを構築していますが、この設計上の問題に 1 週​​間か 2 週間苦労しています。

44 種類のエントリがあり、カスタム タイプを作成する機能を必要とするプログラムを構築しています。

ユーザーは特定の種類のエントリのフィールドを変更したり、独自のフィールドを定義したりする可能性があるため、エントリの種類ごとにエンティティ クラスを生成するという私の最初のアプローチはうまくいかないようです。ユーザーがいずれかのフィールドまたはスキーマのバージョンを変更した場合 (もちろん、検証の対象となります)、私のクラスは実際にはそれを反映しません。

ユーザーがフィールドを変更できない場合でも、データ スキーマの変更によって現在のデータに問題が生じないようにしたいと考えています。

これらすべてが可能なスキーマを構築するために、次のことを行いました。

dtype

  • ID
  • データ・タイプ

分野

  • id フィールド名

  • fieldDataType (外部キーによって dtype にリンク)

データストア

    ID
    データテキスト
    データ文字列
    データ日付
    データダブル
    dataInt
    fieldID (フィールドへの外部キーでリンク)
    entryID (外部キーによってエントリの id フィールドにリンク)

タイプ ol>id int

    タイプ名
    田畑

エントリ

    ID
    typeid (外部キーによって型の id にリンク)

スキーマは非常に非正規化されていますが、ASP.NET MVC での操作は困難です。

私の 2 番目のクラックは、型指定されたプロパティを持つクラスを作成して、エントリがたまたまどのデータ型であるかを格納することでした。

ドメイン レベルのカスタム クラス public class entry { 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 オブジェクトを使用して編集/作成をマップすることを考えました。

考え？

ロン

4

1 に答える 1

1

あなたの最終的な目標は正確にはわかりませんが、選択肢があるかもしれません。ユーザーが独自のデータ構造を作成できるようにする、非常に動的な「エンティティ」が必要です。C# のような命令型言語は、このようなことには向いていません...そして、動的言語であっても、いくつかの困難に遭遇する可能性が高いと思います。ただし、XML は、その場しのぎで実行時に作成可能な方法で動的データ構造を表現するための優れた方法です。

SQL Server を使用している場合は、以下に示すように、より単純な型を作成し、列の 1 つに「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
)

SQL Server の xml 機能があれば、その xml 列のデータをクエリすることができます。それだけでなく、ユーザーのカスタム構造をスキーマに対して検証する場合は、そのスキーマをデータベースに配置し、そのスキーマに対して xml 列を「入力」することもできます。SQL Server で XML 列を使用することには注意が必要ですが、そうでなければ複雑な問題を簡単に解決できる可能性があります。

于 2009-05-31T05:41:03.773 に答える