if (condiction)
{@link
}
else
{@text //灰色代码，或干脆什么都不显示。
}

下面是我们原来封装的Link，里边有两个参数：

displayAsLink，即何种条件下应该显示为Link，否则将显示为灰色文字。比如product.IsProductManager()是问当前用户（括号内无值时自动采用当前用户）是否是产品经理。是，才显示链接。

grayTextTitle，显示为灰色文字时，以悬停文字解释为何不能访问。

注意还有一个displayAsBoardTextOnPage:this（this是当前Page）是问当前Page是否就是链接所在地，如果是就显示为黑体文字而不在显示连接了。

        @MFCUI.ImageLink("只读树", "/ProductManagement/StoryTrees/IndexTree?" + Request.QueryString,displayAsBoldTextOnPage: this, title: "只读故事树，速度较快")@MFCUI.ImageLink("操作树","/ProductManagement/StoryTrees/OperateTree?" + Request.QueryString,displayAsBoldTextOnPage: this, title: "可拖拽和执行所有操作，速度较慢",displayAsLink: product.IsProductManager(),grayTextTitle: "需要是此产品的产品经理才能操作。")@MFCUI.ImageLink("详情树","/ProductManagement/StoryTrees/DetailsTree?" + Request.QueryString,displayAsBoldTextOnPage: this, title: "适合快速查看所有故事的详情")@MFCUI.ImageLink("编辑树","/ProductManagement/StoryTrees/EditTree?" + Request.QueryString,displayAsBoldTextOnPage: this, title: "适合连续编辑多个故事的数据",displayAsLink: product.IsProductManager(),grayTextTitle: "需要是此产品的产品经理才能操作。")

这个方法解决了前面提到的if-else满天飞的问题，但是要解决缺陷更改造成的代码改动还不行。
此外，一些解释性的语言如“需要时此产品的产品经理才能操作”也存在多处文字的统一问题；甚至即使在同一地方，如果displayAsLink修改了条件，而grayTextTitle没有相应修改，会造成用户的错误理解。

其实上面四句话中，能访问或不能访问，都是关于product的写操作权限的，那么如果用product自己来判断，那么代码就会集中在product内部，由专业维护此类的人员来确定权限和解释。

这个是现在为止最佳的选择。

当前View调用处的代码如下：

        @product.IndexTreeLink(this)   @product.OperateTreeLink(this)   @product.DetailsTreeLink(this)   @product.EditTreeLink(this)

Product类中代码如下：

    public partial class Product : Item{public MvcHtmlString IndexTreeLink(WebViewPage page){var queryString = page.Request.QueryString.ToString().Contains("rootID") ? page.Request.QueryString.ToString() : "rootID=" + ID;return MFCUI.ImageLink("只读故事树","/ProductManagement/StoryTrees/IndexTree?" + queryString,displayAsBoldTextOnPage: page, title: "只读故事树，速度较快");}public MvcHtmlString OperateTreeLink(WebViewPage page){var queryString = page.Request.QueryString.ToString().Contains("rootID") ? page.Request.QueryString.ToString() : "rootID=" + ID;return MFCUI.ImageLink("操作故事树","/ProductManagement/StoryTrees/OperateTree?" + queryString,displayAsBoldTextOnPage: page, title: "可拖拽和执行所有操作，速度较慢",displayAsLink: IsProductManager(),grayTextTitle: "需要是此产品的产品经理才能操作。");}public MvcHtmlString DetailsTreeLink(WebViewPage page){var queryString = page.Request.QueryString.ToString().Contains("rootID") ? page.Request.QueryString.ToString() : "rootID=" + ID;return MFCUI.ImageLink("详情故事树","/ProductManagement/StoryTrees/DetailsTree?" + queryString,displayAsBoldTextOnPage: page, title: "适合快速查看所有故事的详情");}public MvcHtmlString EditTreeLink(WebViewPage page){var queryString = page.Request.QueryString.ToString().Contains("rootID") ? page.Request.QueryString.ToString() : "rootID=" + ID;return MFCUI.ImageLink("编辑故事树","/ProductManagement/StoryTrees/EditTree?" + queryString,displayAsBoldTextOnPage: page, title: "适合连续编辑多个故事的数据",displayAsLink: IsProductManager(),grayTextTitle: "需要是此产品的产品经理才能操作。");}}

刚才查找替换了一下，每个链接都出现过6次。通过改写后，原来有很多可能导致不一致的参数的调用都变成一个只传输(this)的参数了，未来维护会简单地多。

下面是一个具体的实现效果：

方法4：重写MVC的Authorize属性

方法3虽然很好，但是只是隐藏了链接而已，真正要访问，手工输入链接仍然可以。

asp.net 为我们封装了一个Authorize的属性，可以这样来简单阻止非法访问（第一行代码）：

        [Authorize(Roles = "ProductManager")]public ActionResult OperateTree(int rootID, string whats, string whattypes){...var root = _repository.ReadItemAt(rootID);var product = root is Product ? root as Product : root.YoungestAncesstor<Product>();if (!product.IsProductManager())return Content("只有此产品的产品经理才可以操作。");return OperateTreeView(...);}

可惜有这么几个限制：

1. 只提供Users（常量的用户名，基本没什么用）和Roles（上例中的）两种。

比如上例中“此产品的产品经理”，就只能编码实现。

2. （似乎）没有地方查看某个Action具体访问权限是什么

也就是说，不能在别处生成指向此Action的链接时，自动根据所限定的Users或Roles来自动决定显示为链接或文字。

重写Authorize可以根据自己的条件来限制访问，唯一的问题是“自己的条件”如果太多，那么会很复杂。

还好，到现在为止火星人中就用了两种限制：

1. 某人是某个角色。

比如SiteUsersController只有Admin才可以访问，这个是站点的用户管理功能。

2. 某人是某物的某个角色。

现在火星人中，“某物”包括产品（的产品经理）、团队（的项目经理、项目助理经理即项目经理不在时应急用的代理人、项目组员）、用户故事（的负责人、当前负责人、创建者）、缺陷（的创建人、当前负责人）……，未来还有部门（的经理、部门助理经理、部门人员）……这些。
这些虽然听起来很多，但是还好之前为了存储问题，产品、团队、用户故事、缺陷……这些都是从基类UDCable（User Defined Column-able，“可被用户自定义字段的”）派生的，而刚才说的一大堆角色，都是一个个UDCType（User Defined Column Type，“用户自定义字段类型”），这样其实所有刚才说的判断，都是一种，就是问某人的Id是否等于某个UDCable的某个UDCType字段数值。

现在还没时间写这个Authroize（主要是不会写，呵呵），估计写好后使用方法如下：

        [Authorize(Roles = "ProductManager", UDCRoles="rootID, ProductManager")]public ActionResult EditTree(int rootID, string whats, string whattypes){...return OperateTreeView(...);}

UDCRoles="rootID, ProductManager"是说，用url的rootID数值来找UDCable，然后判断其"ProductManager"是否等于当前用户。

用这个属性后Action中可以减少3行（一共才5行，所以3行很多了），而整个代码中有很多这样的三行代码，估计现在有30处左右，都很容易写错造成漏洞。

剩下一个问题，@MFCUI.ImageLink怎么知道这些Action的访问权限呢？

现在的想法是在属性代码中用"Area/Controller/Action"作为Key，权限设置（就是“rootID, ProductManager”）作为值做一个静态缓存，ImageLink会根据自己传入的Url解析出“Area/Controller/Action”并去查找缓存的值，如果找到就根据权限进行判断是否显示为链接）。这样未来只要在Action前面写好属性，所有指向它的链接都会自动判断。

因为之前已经有很多可用的代码了（比如解析A/C/T的代码），所以估计两者加起来大约有10～15行代码就能实现。

估计这些代码两个月后才会排到足够优先级，写好了我共享一下。

总结

所有代码结构中的第一块积木是最难的，如果不是我们原来有一些复用了，上面这个访问权限问题解决起来可能需要上百行代码，很容易将就一下就硬编码过去了。

如果我们当年所有View里边的链接都是用<a></a>硬编码的，或用MVC中自带的Hmtl.Link()写的，那么我们也没有勇气和动力来用“这么复杂”的方式来解决这个访问权限问题了。但若干时间后，一旦访问权限变化了，肯定会因为各地的硬编码而出现无数问题，那时候就真的乱了。

UDCable和ImageLink这些都是接近一年半年前产生的，那时候完全没想到会与现在要做的权限控制相关。只能说，如果做对了事情，回报是迟早的。

所以应该随时随地把可复用的东西总结起来，这样反而不觉得累，才能不断在原来的基础上前进。