王石者，或言其安徽人也，其籍不可考，或传其父从定西侯震征新疆，有功，后为柳州转运使，中年得石，极宠之。及石长，有大志，狼行鶻顾，时人异之，昔粤省督以女妻之。石倚父翁之名，周旋商贾，无不得心应手，后以地产为业，竟致富可敌国。石好登山，每出，必耗资百万，尽兴而止。其人又好自传，开博客，书其事，图其影，以为宣传，纵行小善，必勒石以记，其好名如斯。好事者奉为偶像，附于其门下者多矣。

五月祭歌：
五月之央，天携吾芳
断壁残垣，魂绕空梁
何斯如斯，我悲我惶
惟余幽冢，千里茫茫

稚灵长哭，风雨敲窗
雨霁虹垂，永爱彰彰
母失儿女，鸟别家乡
肃肃离鸽，栖翼天堂

其陶其惧，春草秋霜
昨夜绕膝，今夜罹殇
痛失吾爱，何之何往
馀生长忆，朝荣为光

同心断金，英雄抚伤
普天齐唁，慰此凄凉
救治不息，余震难狂
白驹止步，世共昊苍
中国一心，同沐昭阳
希望永存，勇毅如钢
笃信不移，真爱无疆
天堂之鸽，殷殷相望

稚灵长哭，风雨敲窗
雨霁虹垂，永爱彰彰
母失儿女，鸟别家乡
肃肃离鸽，栖翼天堂

 

     摘要:   阅读全文

和 飞过海 还是 护身符哈 ， 和是是护 还是 呵呵 ， 和

还是 ， 还是 护身符哈 呵呵 ， 和是是护 和

还是 护身符哈 呵呵 ， 和是是护 和  输多发 嘎撒递归 嘎大嘎 大幅度 过大撒 嘎

本系列目录 

想必大家已经喜欢上了ListView的布局方式，在LayoutTemplate中定义展现方式，在其它模板中定义数据绑定，使得我们设计数据表现页更简单了。

不过我最近在想一个问题，如果listview中要显示的列并非固定的，或者我们要在其中实现列的重新排列该怎么办呢？本篇文章将要讲述如何动态的为listview创建模板。

首先是第一种简单方式 this.ListView1.LayoutTemplate = this.LoadTemplate("MyTemplate.ascx")；这是最简单的一种方式，但是相对的灵活性也不足，他只能是为我们的listview提供可预知的集中模板。并不能在用户操作的时候实现改变。那么该怎么办呢？

若要创建动态模板，就要先创建模板类，然后在需要时实例化该类。


创建实现ITemplate接口的新类，并实现接口的InstantiateIn方法。
    该方法提供将文本实例或控件实例插入容器的方法。
    我们以LayoutTemplate为例

    public class MyLayoutTemplate : System.Web.UI.ITemplate
    {
        public void InstantiateIn(System.Web.UI.Control container)
        {
            PlaceHolder ph = new PlaceHolder();
            Table t = new Table();
            TableRow r = new TableRow();

            r.Cells.Add(new TableCell() { Text = "Title1" });
            r.Cells.Add(new TableCell() { Text = "Title2" });
            r.Cells.Add(new TableCell() { Text = "Title3" });
            t.Rows.Add(r);
            TableRow itemPlaceholderRow = new TableRow();

            Table itemPlaceholderTable = new Table();
            itemPlaceholderTable.ID = "itemPlaceholder";
            itemPlaceholderRow.Cells.Add(new TableCell());
            itemPlaceholderRow.Cells[0].Controls.Add(itemPlaceholderTable);

            t.Rows.Add(itemPlaceholderRow);
            ph.Controls.Add(t);
            container.Controls.Add(ph);
        }
    }

然后我们只需要创建这个类的实例并将其赋给LayoutTemplate属性就OK了。

            MyLayoutTemplate myLayoutTemplate = new MyLayoutTemplate();

            this.ListView1.LayoutTemplate = myLayoutTemplate;

下面我们创建ItemTemplate，在这里我们还要额外多处理下DataBinding事件。
结果代码如下


同样的，使用this.ListView1.ItemTemplate = new MyItemTemplate();完成ItemTemplate的编辑。

如果你愿意多花点时间，您肯定可以举一反三的搞定其它类型的模板。

(转载请注明出处)      摘要:   阅读全文

在各种企业级系统开发的过程中难以避免都会遇到权限处理的设计。好的权限系统不但能为系统提供安全的解决方案，同时还能节约开发时间，提高系统的可维护性。
权限需求分为两类：
A、模块权限
    操作功能模块的权限，或者访问菜单的权限。比如用户U有没有权利操作“发票界面”。
B、数据权限
    数据权限是对访问数据范围的控制。
    比如有1000张发票用户U有权利操作哪些发票的控制，是操作所有的发票还是自己创建的发票或者是自己部门的发票。
C、字段权限
    在有些时候我们会对特殊字段设置权限，比如客户服务部是不可以看到客户合同额的。
D、操作权限
    操作权限是用户对数据操作方式的控制，是创建、修改、删除或者其它特殊权限，如共享等。
    操作权限一般是基于模块权限的。比如对用户U的发票模块操作权限的控制。但是有时候也会出现特殊情况，比如数据录入员可以创建所有的数据类型而不能浏览、修改、删除数据。

要创建适合自己项目的权限控制框架，需要根据自己项目需求来决定，适合自己的才是最好的，片面追求灵活与功能强大未必能给用户提供最佳体验。在决定使用什么权限框架的时候建议使用能满足自己项目需求的最简单的解决方案。

按需求分的话一般会有几种的等级出现。
1。固定角色
    由系统提供固定的几种角色，这样的系统一般需求比较稳定，变化较少。比如论坛，提供管理员、版主、会员、非会员几种简单的角色进行权限的控制，就足够适应需求。使用这种方式由于角色固定，我们就可以在代码中采用硬编码，所以控制角色权限也好、控制数据权限也好都会比较简单。这种控制方式简单有效，能在最短的时间内提供很好的安全控制。编码简化不仅仅会降低开发成本，同时也会降低维护成本，更重要的用户操作也会简化，易用性明显提高。
    如果你的系统使用这种方式就可以解决问题那么绝对不提倡使用其它的解决方案。很多同事都会说这样如果遇到需求变化不就会经常的需要修改代码吗？需求是层出不穷的，为了未可知的需求去大动干戈，在一些未必会发生的事情上浪费你的宝贵时间我认为是非常不值得的。能够满足一段时间内的需求同样可以称为一个好的系统。
    当然，如果你能明确的知道在未来不长的时间内这种方式并不能满足你的需求的话，可以考虑下面的方案。
2。动态角色：
    很多项目并不是几种固定的角色就能满足系统要求。由于企业经营方式的改变可能会设置更多的岗位，更多的岗位带来更多的角色需求。这时候采用固定角色就非常的失策。
    a、模块权限：
        创建动态角色来控制模块权限并不复杂。我们只需要几个表“功能表”“角色功能表”“用户角色表”就可以实现我们的系统。
    b、数据权限
        数据权限的控制，一般会与组织结构相关。在微软的CRM中数据权限被分为全局、部门、下属机构、 拥有等几种。
            全局：所有数据
            部门：当前部门的数据，不包括下属机构。
            下属机构：下属机构的数据，不包括本部门。
            拥有：自己拥有的或者创建的。
        具体范围等级的划分也需要根据自己项目需求的不同而具体对待。比如，全局、下属人员、自己等。
    c、字段权限
        字段权限的控制属于权限控制中最繁琐的控制，因为字段权限的控制往往会脱离权限控制的范畴影响界面布局。
        字段权限一般是依托与模块权限的，我们需要设置“模块字段表”，与“角色模块字段表”来存储角色拥有的字段权限范围。
    d、操作权限
        操作权限是对具体某种用户操作权限的控制，操作权限的控制往往也依托于模块权限，偶尔会有特例。
        不基于模块的操作权限相对简单，只需要对操作权限设置“角色操作表”做单独处理即可。
        基于模块的操作权限的控制相对复杂，需要设置“模块操作表”来维护模块拥有的操作类型，同时设置“角色模块权限表”来控制角色拥有的模块操作范围。
    
    （ 注：上面提到的各个表只是举例，并非什么经典设计。）
    
事情往往会比上面列出的各种情况更复杂，当各种权限纠集在一起就变得更棘手。
例如在CRM中就会出现同时并存的情况，首先是基本的动态角色权限，然后是基于角色的模块权限，然后是基于模块权限的操作权限，又有与模块权限交错的数据权限，再加上让人头疼的字段权限。我们就陷入了一片苦海。

    最后还是要提醒各位同行在开始您的设计之前一定要搞清楚自己的项目需求，只有依托于需求的设计才能是好的设计，更不会白白浪费你的汗水。千万不要迷失在追求全能的理想境界之中。

ps:以上只是本人的一点看法，如有遗漏错误还请指正。至于更详细的表设计和代码实现在有时间的时候本人尽力奉上。
    （原创，转载请注明出处。）

     摘要:   阅读全文

是从业务流程入手？
还是从关键对象开始？

     摘要:   阅读全文