読み取りカタログ

テキスト

はじめに：「我々は現在ログインして別のユーザーに応じた受注データの種類を見ることを期待して、注文のリストを持っている」、我々は別のシステムのユーザーが必要」「私たちは、異なるユーザが異なる期間におけるスキャンレポートデータを見ることができますしたいです」異なる生産レポート列を表示します。」権限が備わっていますデータの共通セットの上に構築され、現在の開発フレームワークで：だから、上の最近の決定を議論する会議の後、多くの場合、プロジェクト以上の顧客が提起したこの質問、いわゆる「デジタル著作権」を受けました。

この記事オリジナル住所：http://www.cnblogs.com/landeanfen/p/7760803.html

トップへ戻ります

まず、横たわっ権限モジュール

データのアクセス許可-上記の導入に伴い、当然議論の話題今日とニーズにつながります。開発者は、我々は確かに知っているように、一般的なシステムは、システム全体の基本的なモジュールをサポートすることです許可モジュール、なくてはなりません。そして、プロジェクトの種類と要件に応じて、意匠権モジュールは異なっています。：しかし、彼らがどのように変化するかに関係なく、権限が大きい側からモジュール、それは2つの主要なタイプに分けることができ、機能の権限 と データ権限。

ファンクション権：本体制御異なるリソース（ユーザー、ロール、組織など）が異なるリソースを操作する権限を持っています。共通異なる役割が異なるページ（メニュー権）だけでなく、持つさまざまな機能（ボタンの権限）、などの操作を同じページにアクセスすることができますなど、すべてのデータが適切なカテゴリに機能し、この設計は比較的単純で、より多くのほとんどのためにユニバーサルシステム。もちろん、オンライン情報、デザインのアイデアもたくさん見つけることができます。
データアクセス権：別の本体制御リソース（ユーザー、ロール、組織など）の異なるデータを表示する権限があり、一般的には、データ権限が分割されたデータの権利の行とデータ列権限文字通りの意味では、理解するのは難しいことではありませんそのような、これは典型的なデータラインの権威である「私たちは現在ログインしている別のユーザーに応じた受注データの種類を見ることを期待して、注文のリストを持っている」と、上記のように2つの違いは、「我々は、異なるシステム・ユーザーが異なる表示する必要があります生産報告書の欄には、「これはデータ列の権限の範疇です。ビジネスロジックとデータ権制度は非常に近いので、その異なるデザインは非常に大きな違いになります。システムのビジネスロジックが非常に複雑である場合の権限に関する設計データは比較的一般的で使いやすいされていないので、一方、データ権限と関連するビジネスロジックから、データの権利は一緒に比較的複雑な設計になり、非常に強いですそれは設計します。

あなたはハンズオン設計データのアクセス権を行く場合は、主要なプラットフォームに行くと、百度、デザインのアイデアのために、Googleの外観は、あなたはそれが困難な有用な情報を見つけるために見つける、デザインのアイデアの多くの制限が非常に大きいです。実際には、理由は簡単です。他のシステムに密接な関係の設計やデータの権限、通常は簡単にあなたのプロジェクトの上に直接慣れしていません。

もちろん、人々の別の部分は、言う「データの権利と、モジュールを設計するための権限として使用することはできません」などのブロガーのようなコメントを見ています

ある程度までは、この理解はあなたのシステムの柔軟性と設定はそれほど高く必要がないと感じた場合、データの規則は害内部のデッドコードの許可、会社のブロガー別の部門を書かれ、過大ではありませんそれは問題のあまりないことを大コーディングに加えて、とても乾燥しています！あまりにも多く、実際には、ブロガーは、単に視点を表現したい：絶対的な権利の共通データデザインのアイデアは、キーはあなたと一緒に収まるようにありません！もちろん、この記事では、共通のはもちろんのこと、必須、同じデザインのアイデアではありません。あなたの参照のためのアイデアをデザイン！

トップへ戻ります

第二に、1つの設計思想

デザインのトピックに関する権限が最後に来るのを、すべての表面的な、腐ったと言うより言います。これまでのところ、ブロガーは比較的によく書かれた記事を見つける普遍的な権利のデータ著作権管理の設計を。これは、内部に適用されている場合ブロガーは、達成するためにSQLを使用している、そしてEF、EFは、アカウントにナビゲーション属性の複雑さを取って、いくつかの問題があるでしょう。そして、ブロガーがここに考えるデザインのアイデアについて話しています。

私たちはブロガープロジェクトの場合についてお話しましょう、いくつかの伝統的なデータを扱うとモデルEntityFramework +リポジトリは、上から下まで全体のプロジェクトは、典型的な「疑似DDD」、「擬似DDD」は何である、達成すべきでしょうか？ここで説明するのあまりしないでください、使用DDDの同僚は、非常に明確にする必要があります。以下は、デザインのアイデアを説明するためのフローチャートです。

ステップ1：設定データ・ルール

ステップ2：ページが使用するデータ・ルール

上記の主に2つのステップに分け基づいて、設計データ権限EFを達成するために、一般的には、描画の目安です

トップへ戻ります

図1に示すように、コンフィギュレーション・ルール・データ

：ここで設定したデータ・ルールは、三つの主要な領域であり、機能モジュール、データリソース、役割

機能モジュール：なぜここ制約機能モジュールを追加するには？我々は1つのページのクエリデータ内ブロガーは、ときにそのようなページ順の問い合わせが確かに機能にリンクされているエンティティを照会して注文することができますように、クエリの範囲が存在しますが、クエリと、それはそれに関連するビジネスを持っていないことはできないと感じているので。プラス大きな意義は、我々がラムダは、エラーのような「に関連した実体」を生成しません構築動的なエンティティを照会するためにバインドされます。
データリソース：このような順序状態を解除するために等しくない、一回の命令の下少ない現在の月よりも、などの状況などのデータの権限を、実行するデータリソースの特定の種類。
役割：メインのデータリソースが、また、ユーザー、部署、組織、およびその上に置くことができます。

这三者配置之后得到的一个结果就是某一类角色的某一个功能模块对哪个数据资源的数据规则是什么样的。比如有一条销售总监的数据规则，配置销售总监在订单模块里面订单这个实体的订单类型是销售订单的所有数据，这就是针对销售总监在订单模块的数据规则。可能最终数据库存储得到的数据类似这样：

RoleId	FunctionCode	Rules
2	OrderQuery	{"rules":[{"field":"Order_Status","operate":"in","value":"[0,1,2]"},{"field":"Order_Type","op":"equal","value":"1"}],"logicoperate":"and"}
3	OrderQuery	{"rules":[{"field":"Order_Status","operate":"in","value":"[0]"},{"field":"Product.Categary.Type","equal":"equal","value":"1"}],"logicoperate":"and"}
5	Product	{"groups":[ {"rules":[{"field":"Order_Status","operate":"in","value":"[0,5,10]"},{"field":"Order_Type","op":"equal","value":"1 "}],"logicoperate":"and"}, {"rules":[{"field":"LineName","operate":"equal","value":"fenzhuangxian"}]} ],"logicoperate":"or"}

需要特别说明的是：由于EF有导航属性，这里的Rules在保存的时候如果遇到导航属性，我们的字段值需要这样保存——Product.Categary.Type。因为在我们转换成为lambda表达式的时候导航属性会是这样写：x=>x.Product.Categary.Type==1。这个我们在后面使用这个规则的时候加以说明。

回到顶部

2、使用数据规则

有了上面的数据规则，接下来就是我们在取数据的时候如何使用了，这里有一点需要说明的是：我们这里需要传两个参数，一个是模块的名称，比如上面的OrderQuery、Product等；第二个是当前用户的角色id，这个可以通过当前登陆用户的id获取到角色。

要使用数据规则，之前博主分享过两篇关于动态Lambda的文章，现在派上用场了。只不过原来只是一些基础类型转lambda，现在涉及到了导航属性，不知道是否可行。博主查阅了一些资料，最终找到了解决方案。

　　　　 //遍历得到属性（包括遍历导航属性）
        public Expression GetProperty(Expression source, ParameterExpression para, string Name)
        {
            string[] propertys = Name.Split('.');
            if (source == null)
            {
                source = Expression.Property(para, typeof(Entity).GetProperty(propertys.First()));
            }
            else
            {
                source = Expression.Property(source, propertys.First());
            }
            foreach (var item in propertys.Skip(1))
            {
                source = GetProperty(source, para, item);
            }
            return source;
        }

然后测试如下

　　　　　　　　　　　　var oLamadaExtention = new LambdaExpression<Order>();
                    var left = oLamadaExtention.GetProperty(null, Expression.Parameter(typeof(Order), "x"), "Product.Categary.Type");
                    var value = Expression.Constant("1", left.Type);
                    //动态转换类型
                    var right = Expression.Constant(value, left.Type);
                    Expression expRes = Expression.Equal(left, right);

测试得到的查询lambda结果为x=>x.Product.Categary.Type=="1"，测试成功！

回到顶部