敏捷开发“松结对编程”系列之十六：L型代码结构（编程篇之二）（上）

本文是“松结对编程”系列的第十六篇。（松结对编程栏目目录）

今天正好要复用一段框架（asp.net MVC3，服用范围包括Controller和View），把过程记录一下。

与复用一般的过程相比，L型代码结构有这么几个特点：

1. 如果复用有难度，在复用之前，一般不刻意形成“可复用代码”。顺便就能写成函数的例外。

2. 从第二次复用的时候，就形成复用代码。

这个听起来很容易，但要求：编写复用代码的人，就是调用复用代码的人，否则他不知道是否会复用，以及复用到第几次了。换言之，不要安排人刻意编写复用代码，否则很容易还没人用，或只用一次，就费劲写了一个可复用代码；又很容易大家一直在重复的东西，他却不知道。如果能一边编写上层应用知道使用的实际情况，一边编写底层可复用库，就能避免这种情况。

业务需求现在需要编写一个对产品线下的产品进行“增删改查”操作的业务。想象中的界面如下（实际是完成后的截图）：
想到之前曾经编写过一个为部门下的团队进行“增删改查”操作的业务，界面大致如下：

决定借用这个页面，顺带把代码也全部借用了（除了里边不显示人员列表外，几乎没有区别），而且这两个东西的基类还是相同的（这一点很重要），分别是

Product : Item（父子关系项） : UDCable（可自定义字段的）

Department: Item（父子关系项） : UDCable（可自定义字段的）

注意下面代码中的Program（部门）和Team（团队，隶属于部门）基类都是Department。

原来Teams的处理代码如下：

4. 用这个框架实现Product的页面：
C#代码就一行，在ProductsController.cs里边：
        public ActionResult Index(int? productLineID)        {            return MFCDefaultView(productLineID ?? _repMFC.ReadAllItems<ProductLine>().First(i => i.Type == ItemWhattype.ProductTypeProductLine).ID);        }

View只有一个，就是体现Team和Product中间显示不同的部分，下一篇再写。
残留问题
但最后会遇到几个最关键的问题：
1. team要显示成员，product要显示别的（暂定为最近的发布Release）。
Index实际上不知道这件事情，因为它只收到了Item，这个基类中并没有成员或发布Release的信息。
2. 新建好team要转向成员分配(/TeamMembers/Index)，新建好product要转向创建发布(/Products/ReleaseSchedule)。
3. 哪些Action需要写View，然后在View里边RenderAction（比如这个Teams/Index）；哪些不用写View，直接在Controller的Action里边RedirectToAction到ItemsController的操作？（这样简单，连View都不用谢，但有局限就是Url会跳转）？
4. 这些编码方法与松结对编程有何关系？
这两个问题的解决，下一篇再写。