Agile development "loose pair Programming" series 16: L-Type Code structure (ii) (i) __ programming

This is the 16th article in the "Loose pair programming" series. (Pine pair Programming column directory)

Today it's time to reuse a frame (asp.net MVC3, take the range including controller and view) and record the process.

There are several features of the L-code structure compared to the general process of reuse:

1. If it is difficult to reuse, before reuse, generally do not deliberately form a "reusable code." By the way, you can write an exception to the function.

2. The reuse code is formed from the second time of reuse.

This sounds easy, but the requirement: the person who writes the code for the reuse is the person who invokes the code, otherwise he doesn't know if it will be reused and how many times it has been reused. In other words, do not schedule a person to deliberately write the reuse code , otherwise it is easy to have no one to use, or only once, the effort to write a reusable code; it's easy to keep repeating things, but he doesn't know. If you can write a high-level application to know the actual use of the situation, while writing the underlying reusable library, you can avoid this case. Business Requirements now need to write a product line products under the "Check and delete" operation of the business. The imaginary interface is as follows (actually the screenshot after the completion):
Think of the previous written a team for the Department of "additions and deletions to check" the operation of the business, the interface is roughly as follows:

decided to borrow this page, incidentally the code is also all borrowed (in addition to the inside does not show the list of people, almost no difference), and these two things are the same base class (this is important), respectively, is

Product:item (Parent-Child relationship Entry): udcable (customizable field)

Department:item (Parent-Child relationship Entry): udcable (customizable field)

Note that the program (department) and Team (group, subordinate to department) base class in the following code are department.

The original teams processing code is as follows:

        Public ActionResult Index (int. ProgramID)
        {return
            Mfcdefaultview (programid??? _repmfc.readallitems< Program> (). (i => i.type = = Itemwhattype.departmenttypeprogram). ID);
        

        Public ActionResult Create (int programid, string redirecttoaftercreated, string returnurl = null)
        {
            return Redirect ("/mfc/items/create?fatherid=" + programid
                            + "&what=" + systemitemwhat.deaprtment + "&type=" + Itemwhattype.departmenttypeteam + "&returnurl=" +
                            Httputility.urlencode (ReturnUrl));
        }
    ...
    }

Delete, move around, edit the code is not in this inside, is by Itemscontroller is also their base class item of a public controller processing. Originally index/create/edit/details there are public code and interface, but because the team's page is more special, such as after each creation is not returned to the index page, but to the member allocation page, so all over the side to do the function and page, But some of them point to functions in Itemscontroller, such as the above create ().

New business requirements are similar to this, so instead of writing another one, it's better to refactor it and use it later, from the code to the interface, to be used directly. Refactoring Order

This reuse-induced refactoring has a number of working orders, roughly two:

1. First write that productscontroller, then compare the difference with the Teamscontroller, then extract the common part of the reuse, and then the teams and products two are based on the reuse implementation

The downside is to write both sides, and the ProductsController and the corresponding few view will soon be thrown away.

This is suitable for beginners through the comparison of the discovery of reusable code extraction, is inefficient, only for learning to use.

2. Directly write a reusable bottom layer, based on the underlying write ProductsController, after the Teamscontroller also according to the bottom of the implementation.

The downside is that the bugs in the products themselves may be entangled with the bugs at the bottom, debugging trouble.

3. First, according to teams write a bottom, and then teams written on the basis of reusable code, debugging passed directly on the bottom of the products to write products.

The disadvantage is that perhaps only looking at the teams may not be able to write a reusable bottom, need to take more experience.

The advantage is that the debugging process is simpler, and you can use Teamscontroller as a test case to test that reusable bottom.

I choose the method 3 (not because it is the best, before the code is not much time to choose over 1, more confident when the choice of 2). Only the index function is processed in the refactoring step Step (create function see next article). 1. Write an action to replace Teams/index in the Itemscontroller first.

This new function is called Itemhorizentallist bar (horizontal list)

        Public ActionResult itemhorizentallist (int rootid, string What, String type, string ReturnUrl)
        {
            var root = _REPMF C.readat<item> (Rootid);
            Ienumerable<item> subitems = root. SubItems (). Where (i => i.what = = What && I.type = = Type);
            return Mfcdefaultview (root, subitems, what, type, ReturnUrl);
        }

Rootid indicates which department program under the team, or which product line productline under the product product,whats and Whattypes is determined to show what type of item, an item in the end is the department program/ Team team/product line productline/product products, it is up to them to decide.

The back of this return mfcdefaultview is temporarily ignored, and its job is to transfer multiple parameters to the view at the same time. Previous asp.net controller.view () can only pass a parameter, to pass multiple will use ViewBag, or ViewModel (although "ViewModel" is a design pattern, but not only to write a ViewModel, Also often go inside to look inside the code, very damaging code readability. This mfcdefaultview can pass in the variable parameter list, in pagedata[] in order to read, that is, the process of calling a view is very much like call a function. This is also what we have just encapsulated recently, and then to Iewbag and ViewModel say good-bye. 2. In this new Actoin view to achieve the original Teams/index work

Original View Code (views/teams/index.cshtml):

    This. Initializelayout ("team");

    
The <div> above shows the new button in the beginning of the article, and the following renderpage shows all the teams on the right.

What exactly are the parameters that need to be parameterized inside? Usually with department, team,/site/teams/... , you have to parameterize. You can look at the results below.



New View (views/items/itemhorizentallist.cshtml):


    var root = pagedata[0] as Item;
    var subitems = pagedata[1] as ienumerable<item>;

    <div class = "Item-hierarchy @MFCUI. Hovertwinkletriggerbodyclass ("Create-new-team") "style =" float:left; margin-right:16px; min-height:10px; min-width:10px; " >
        <div class = "Item-hierarchy-body" >
            @MFCUI. ImageLink ("New", "/mfc/items/create?rootid=" + root.id + "&redirecttoaftercreated=" + httputility.urlencode ( redirectaftercreate),
                           imgurl: "/mfc/items/create48.png", Showtext:false)
        </div>
    </div>
    @RenderPage ("itemhorizentallist/_subitems.cshtml", subitems, false)
 

The previous heap of Var mfcdefaultview the parameters mentioned in 1, and the middle Div and the back renderpage are modified according to the parameters.

What parameters are required depends on how the original action for the team becomes the general item. 3. Adjust the partial view called by the new view

Then a little adjustment, gradually turn _subteams.cshtml into _subitems.cshtml,_team.cshtml into _subitem.cshtml.

Because both product and team are derived from item, it is OK to act as an item.

Refresh the page and see the effect. Gradually, the interface is normal:


4. The page that implements product with this framework:

The C # code is on one line, inside the ProductsController.cs:


        Public ActionResult Index (int. Productlineid)
        {return
            Mfcdefaultview (Productlineid??? _repmfc.readallitems <ProductLine> (). (i => i.type = = itemwhattype.producttypeproductline). ID);
        
 

View is only one, is to show the team and product in the middle of the display of different parts, the next write.
Residue Problems

But in the end there are some of the most critical issues:

1. Team to display the members, product to display something else (tentatively the latest release released).

Index actually doesn't know about this because it only receives the item, and there is no member or release information in the base class.

2. New good team to switch to member allocation (/TEAMMEMBERS/INDEX), new good product to create a release (/products/releaseschedule).

3. Which action needs to write view, and then in the view inside renderaction (such as this teams/index), which do not write view, Directly in the action inside the controller redirecttoaction to the Itemscontroller operation. (This simple, even the view do not need to thank, but there are limitations is the URL will jump).

4. How these coding methods relate to loose-knot programming.

The solution to these two problems is to write the next one.