2007年12月24日

同样是替代传统的”header+ foreach + footer ”的方法，我做了两个扩展方法，分别是Repeater和GridView，因为Repeater相对简单和基础，用于轻量级的情况。这里先把Repeater发上来。

首先明确一下这个Repeater的功能：

1、能够根据需要自由转换<div>,<table>,<ul>标签等格式，也可不套用任何格式。并且当使用Table时，可以随意指定其每行显示的单元格数，当最后一行有零头时，自动填充剩余的空单元格。

2、能够在方法中完成自定义header和footer的工作（类似这些“庞杂”的工作应该说是在MVC中催生出Repeater、GridView等插件的主要动因），让整个Repeater在WebForm中一样达到“一体化”，而不再是这样的局面：

<ul>

<% foreach (var item in collection){%>

<li><%= item %></li>     

<% } %>

</ul>

想象一下在包含thead，tbody的table中将更加复杂。当然这样的形势并不是一无是处的，对于美工等前台控制，这些直白的表达方式更加利于我们的操作和控制。所以必须说明的一点是：当需要对其进行很复杂的操作的时候，不要滥用这些扩展方法，否则会给维护带来很多不便。

为了达到上面说的第一点，我们先建一个枚举类型，用于指定使用哪种格式：

（包含在MvcTool/RepeaterExtension.cs中）

public enum RepeaterMode
        {
            /**//// <summary>
            /// 不自动加任何多于标记，等同于foreach。但header和footer仍然有效
             /// </summary>
            None = 0,
            Table,
            Div,
            Ul
        }

然后我们来建一个RepeaterExtension类，用于在aspx页面的HtmlHelper方法中扩展这个Repeater：

（也包含在MvcTool/RepeaterExtension.cs中）

public class SingleRepeater : IDisposable
        {
           …
        }

        /**//// <summary>
        /// Repeater
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="helper"></param>
        /// <param name="dataSource">数据源</param>
        /// <param name="header">第一个单项循环开始之前的内容</param>
        /// <param name="itemTempletes">单项内容</param>
        /// <param name="separatorTemplate">每次循环分隔内容（Table慎用）</param>
        /// <param name="footer">最后一个单项循环结束之后的内容</param>
        /// <param name="repeaterMode">repeater模式</param>
        /// <param name="colCount">每行烈数（只在repeaterMode为Table时有效）</param>
        /// <param name="htmlAttributes">标签属性</param>
        /// <returns></returns>
        public static string Repeater<T>(this HtmlHelper helper, IEnumerable<T> dataSource,
            string header, Expression<Func<T, string>> itemTempletes, Expression<Func<T, string>> separatorTemplate, string footer,

            RepeaterMode repeaterMode, int colCount, object htmlAttributes)
        {
            …
        }

RepeaterExtension 主要包含了两个方法：SingleRepeater()和Repeater<T>()，因为里面具体实现的代码比较长，这里省略了，大家可以在下面提供的下载中察看MvcTool/RepeaterExtension.cs文件。对于SingleRepeater()大家可能会有点疑问：是否需要存在？是否需要继承IDisposable？我这里就此简要说明一下用意：目前的这些代码中，无论是SingleRepeater()还是继承IDisposable的行为，都是可以被简化并且整合到Repeater<T>()方法中的，这里这么做是为了给页面表现形式留有一个升级的余地，比如在using()中书写等等（为了更好的对页面进行控制）。

public enum RepeaterMode这个枚举大家也可以根据自己的需要扩展，比如<ol>等等。

下面我们来一下aspx如何使用：

<%= Html.Repeater(ViewData.Model.UserInfo,//数据源
    "",//header
    z=> string.Format("{0} ，年龄：{1}", z.UserName,z.Age),//item模板，为了在页面得到数据的完全控制，必须返回string类型
    z=> "",//间隔
    "",//footer
    RepeaterExtension.RepeaterMode.Ul,//重复的方式（table,div,ul）
    0,//如果使用Table，则指定其显示的列数
    null//最外层标签的属性，object类型
    ) %>

其中RepeaterExtension.RepeaterMode.Ul用于指定这个Repeater的展现方式为Ul/Li。

         我们来看看实际输出的效果：

UL(即上述代码输出)：

Table形式（5列）：

不使用任何格式（header为“[”，footer为“]”，间隔为“|”）：


代码下载：/Files/szw/MVCRepeater.rar

PS：这个Repeater扩展对输出内容较为简单的代码能起到很好的提高开发效率的作用，不光在MVC能用，在WebForm里面也是可以的。同时其中的一些思想和参数用法，也是对接下来要讲的GridView的一个基础和热身。下一篇：为ASP.NET MVC开发一些常用插件（四）——GridView。

    ASP.NET MVC Preview3刚出来就发bug，不是想泼冷水，而是一贯的为了和大家一起更好地讨论、学习、使用，大家一起进步。

    Pre3和Pre2的主要区别在Scott的Blog上面已经比较清楚地展示了，并且官方也提供了了一个升级文档：http://weblogs.asp.net/scottgu/archive/2008/05/27/asp-net-mvc-preview-3-release.aspx。
   
    今天大概看了几个关键的地方，目前发现了在ActionURL这个用法上面没有太大变化的地方，但是在获取上面反而有点小问题：

     一、比如当你试图在AdminController（对应的View）里面输出Url.Action("Foo")的时候，理想情况下应该是返回/Admin[.mvc]/Foo，但是不幸的事情发生了，当你在HomeController里面添加一个Foo的Action，并且在global.asax.cs里面添加了一条Home/Foo的URL规则之后（不添加不会有问题），你再用Url.Action("Foo")的时候，返回的将有可能是这样：/Home[.mvc]/Foo，所以为了保证持久的可用性，在这种情况下我们必须放弃Url.Action("Foo")这种方式，转而使用这样的重写方法：Url.Action("Foo","Admin")。不光是Url.Action是这样，Html.ActionLink也存在着同样的问题。我反复在IIS/VS以及routes.MapRoute/routes.Add方式进行了测试，结果都是一样的。这点是很恶心的，不知道是我这里环境的问题还是大家的测试结果也这样？欢迎大家反馈！
   
此bug实例下载：http://www.cnblogs.com/Files/szw/ASP.NET_MVC_Preview_3_-Routing_bug-1.rar
   
    关键测试代码：
    Global.asax.cs：

            routes.MapRoute(
                "About",                                              // Route name
                "Home/About",                           // URL with parameters
                new { controller = "Home", action = "About" }  // Parameter defaults
            );

    /Views/Admin/Index.aspx：

    理想情况：Url.Action("About")应该和Url.Action("About","Admin")输出一样：<%= Url.Action("About","Admin") %><br />
    实际Url.Action("About")输出：<%= Url.Action("About") %>

    输出结果：

---

    另外在这里总结一下之前2个Preview版本的已发现的bug（或者不足之处）的现状：
    这些问题我依次发表在了使用微软ASP.NET MVC Framework的一些感受 + 收集园子朋友发现的bug反馈 ，使用微软ASP.NET MVC Framework的一些感受 + 收集园子朋友发现的bug反馈 【补充】 和MVC Toolkit 部分已发现bug的根治方案 Part(1)

    1、第一篇说到的一些问题，目前还是多多少少存在，但这并不能说明都是MVC本身的问题，有些是.NET3.5的一些特性——比如Linq to SQL——在使用和“配合”上的一些问题。
    2、第一篇、第二篇中提到的HtmlHelper中的很多扩展方法很乱的问题，这次在Preview3中是快刀斩乱麻，所有的size,maxLength之类的属性都放到了htmlAttributs属性中，倒也清爽，升级和使用的时候要多加注意了。
    3、第三篇MVC Toolkit 部分已发现bug的根治方案 Part(1) 中谈到的问题在Preview3貌似已经完美解决了 。


    一些注意点：

官方的升级文档上面有这么一段话： 

·         dit the Default.aspx file and add the following line:

<% Response.Redirect("~/Home") %>

This redirect is not necessary for IIS 7. This is a workaround for an issue with how the Web server that is built into Visual Studio (the ASP.NET Development Server) works with routing.

    大概意思是说找到Default.aspx 并且加入这段代码：<% Response.Redirect("~/Home") %> 。在IIS7中是不需要这么做的，为的是当你用VS测试或者IIS7以下的IIS时候需要用这个来做一个根目录的“跳板”。十分感谢Leven朋友的提醒，使用Preview1/2模板的话，那里的default.aspx没有设定Language="C#" ，默认是VB.NET，Response.Redirect("~/Home")的语法没有错误，用了C#的话后面需要加一个“;”。这里要补充一点文档上没有说清楚的：只是("~/Home") 的话对于IIS7以下的环境是无效的（当然在Preview3的模板中，在default.aspx.cs的Page_Load里已经加入了这个跳转，需要到default.aspx.cs中查看或修改。根据Page_Load和aspx页面的执行顺序，直接在aspx页面设定将是无效的），从Preview1/2上面升级过来的时候还要注意这里的"~/Home"需要和前面的版本修改global.asax.cs一样，如果不是使用IIS7,则需要在后面加一个自定义的扩展名，比如.mvc——"~/Home.mvc"。

    还有一点点期望：
1、Html.DropDownList(原Html.Select)在数据源的类型上可以更丰富一些，特别是直接接受IDictionary<string,object>类型的数据源（目前由于IDictionary<string,object> htmlAttributes的重写方法，这个类型会被认为是一个属性的集合）。当然这在new SelectList()里面还是可以做到的，只是这种“value-text”形式的Html输入框能直接绑定key-value就更好了，目前还要自己扩展一些方法才能做到。
2、Preview3里面一改以往必须在RenderView中输入.aspx/.ascx文件名的要求，可以根据Action名称直接View();并且每个Action都要返回一个ResultAction类型，这时候，我们可以通过return RedirectToAction(actionName)来执行另外一个Action（RedirectToAction 返回的也是ResultAction类型），但是我又想到一个更加方便的方法（不知官方这么用了没有）——直接return actionName()——这个方法除了输入方便，还助于在编译时检测actionName的正确性，以及传参的正确性及便捷性。因为返回类型都是ResultAction。我尝试了之后，发现是可行的，但是有一个跟View()方法有关的问题出现了：比如我在Action1中，return Action2();而在Action2中，我只是View()，没有View("Action2")，这时候由于方法名称还是Action1，所以在运行到Action2的View()的时候，会自动查找Action1.aspx/ascx，而非Action2的。这里有点遗憾，如果View()方法是可以再丰富一下，查找其直接所属的方法的名称，那这个功能就更加完美了。

    更多的细节问题还在确认中，欢迎大家补充，我会一并总结上来！

The singleton pattern is one of the best-known patterns in software engineering. Essentially, a singleton is a class which only allows a single instance of itself to be created, and usually gives simple access to that instance. Most commonly, singletons don't allow any parameters to be specified when creating the instance - as otherwise a second request for an instance but with a different parameter could be problematic! (If the same instance should be accessed for all requests with the same parameter, the factory pattern is more appropriate.) This article deals only with the situation where no parameters are required. Typically a requirement of singletons is that they are created lazily - i.e. that the instance isn't created until it is first needed.

There are various different ways of implementing the singleton pattern in C#. I shall present them here in reverse order of elegance, starting with the most commonly seen, which is not thread-safe, and working up to a fully lazily-loaded, thread-safe, simple and highly performant version. Note that in the code here, I omit the private modifier, as it is the default for class members. In many other languages such as Java, there is a different default, and private should be used.

All these implementations share four common characteristics, however:

• A single constructor, which is private and parameterless. This prevents other classes from instantiating it (which would be a violation of the pattern). Note that it also prevents subclassing - if a singleton can be subclassed once, it can be subclassed twice, and if each of those subclasses can create an instance, the pattern is violated. The factory pattern can be used if you need a single instance of a base type, but the exact type isn't known until runtime.
• The class is sealed. This is unnecessary, strictly speaking, due to the above point, but may help the JIT to optimise things more.
• A static variable which holds a reference to the single created instance, if any.
• A public static means of getting the reference to the single created instance, creating one if necessary.

Note that all of these implementations also use a public static property Instance as the means of accessing the instance. In all cases, the property could easily be converted to a method, with no impact on thread-safety or performance.

First version - not thread-safe

// Bad code! Do not use!

            public sealed class Singleton

            {

            static Singleton instance=null;

            

            Singleton()

            {

            }

            

            public static Singleton Instance

            {

            get

            {

            if (instance==null)

            {

            instance = new Singleton();

            }

            return instance;

            }

            }

            }

            

As hinted at before, the above is not thread-safe. Two different threads could both have evaluated the test if (instance==null) and found it to be true, then both create instances, which violates the singleton pattern. Note that in fact the instance may already have been created before the expression is evaluated, but the memory model doesn't guarantee that the new value of instance will be seen by other threads unless suitable memory barriers have been passed.

Second version - simple thread-safety

public sealed class Singleton

            {

            static Singleton instance=null;

            static readonly object padlock = new object();

            

            Singleton()

            {

            }

            

            public static Singleton Instance

            {

            get

            {

            lock (padlock)

            {

            if (instance==null)

            {

            instance = new Singleton();

            }

            return instance;

            }

            }

            }

            }

            

This implementation is thread-safe. The thread takes out a lock on a shared object, and then checks whether or not the instance has been created before creating the instance. This takes care of the memory barrier issue (as locking makes sure that all reads occur logically after the lock acquire, and unlocking makes sure that all writes occur logically before the lock release) and ensures that only one thread will create an instance (as only one thread can be in that part of the code at a time - by the time the second thread enters it,the first thread will have created the instance, so the expression will evaluate to false). Unfortunately, performance suffers as a lock is acquired every time the instance is requested.

Note that instead of locking on typeof(Singleton) as some versions of this implementation do, I lock on the value of a static variable which is private to the class. Locking on objects which other classes can access and lock on (such as the type) risks performance issues and even deadlocks. This is a general style preference of mine - wherever possible, only lock on objects specifically created for the purpose of locking, or which document that they are to be locked on for specific purposes (e.g. for waiting/pulsing a queue). Usually such objects should be private to the class they are used in. This helps to make writing thread-safe applications significantly easier.

Third version - attempted thread-safety using double-check locking

// Bad code! Do not use!

            public sealed class Singleton

            {

            static Singleton instance=null;

            static readonly object padlock = new object();

            

            Singleton()

            {

            }

            

            public static Singleton Instance

            {

            get

            {

            if (instance==null)

            {

            lock (padlock)

            {

            if (instance==null)

            {

            instance = new Singleton();

            }

            }

            }

            return instance;

            }

            }

            }

            

This implementation attempts to be thread-safe without the necessity of taking out a lock every time. Unfortunately, there are four downsides to the pattern:

• It doesn't work in Java. This may seem an odd thing to comment on, but it's worth knowing if you ever need the singleton pattern in Java, and C# programmers may well also be Java programmers. The Java memory model doesn't ensure that the constructor completes before the reference to the new object is assigned to instance. The Java memory model underwent a reworking for version 1.5, but double-check locking is still broken after this without a volatile variable (as in C#).
• Without any memory barriers, it's broken in the ECMA CLI specification too. It's possible that under the .NET 2.0 memory model (which is stronger than the ECMA spec) it's safe, but I'd rather not rely on those stronger semantics, especially if there's any doubt as to the safety. Making the instance variable volatile can make it work, as would explicit memory barrier calls, although in the latter case even experts can't agree exactly which barriers are required. I tend to try to avoid situations where experts don't agree what's right and what's wrong!
• It's easy to get wrong. The pattern needs to be pretty much exactly as above - any significant changes are likely to impact either performance or correctness.
• It still doesn't perform as well as the later implementations.

Fourth version - not quite as lazy, but thread-safe without using locks

public sealed class Singleton

            {

            static readonly Singleton instance=new Singleton();

            

            // Explicit static constructor to tell C# compiler

            // not to mark type as beforefieldinit

            static Singleton()

            {

            }

            

            Singleton()

            {

            }

            

            public static Singleton Instance

            {

            get

            {

            return instance;

            }

            }

            }

            

As you can see, this is really is extremely simple - but why is it thread-safe and how lazy is it? Well, static constructors in C# are specified to execute only when an instance of the class is created or a static member is referenced, and to execute only once per AppDomain. Given that this check for the type being newly constructed needs to be executed whatever else happens, it will be faster than adding extra checking as in the previous examples. There are a couple of wrinkles, however:

• It's not as lazy as the other implementations. In particular, if you have static members other than Instance, the first reference to those members will involve creating the instance. This is corrected in the next implementation.
• There are complications if one static constructor invokes another which invokes the first again. Look in the .NET specifications (currently section 9.5.3 of partition II) for more details about the exact nature of type initializers - they're unlikely to bite you, but it's worth being aware of the consequences of static constructors which refer to each other in a cycle.
• The laziness of type initializers is only guaranteed by .NET when the type isn't marked with a special flag called beforefieldinit. Unfortunately, the C# compiler (as provided in the .NET 1.1 runtime, at least) marks all types which don't have a static constructor (i.e. a block which looks like a constructor but is marked static) as beforefieldinit. I now have a discussion page with more details about this issue. Also note that it affects performance, as discussed near the bottom of this article.

One shortcut you can take with this implementation (and only this one) is to just make instance a public static readonly variable, and get rid of the property entirely. This makes the basic skeleton code absolutely tiny! Many people, however, prefer to have a property in case further action is needed in future, and JIT inlining is likely to make the performance identical. (Note that the static constructor itself is still required if you require laziness.)

Fifth version - fully lazy instantiation

public sealed class Singleton

            {

            Singleton()

            {

            }

            

            public static Singleton Instance

            {

            get

            {

            return Nested.instance;

            }

            }

            

            class Nested

            {

            // Explicit static constructor to tell C# compiler

            // not to mark type as beforefieldinit

            static Nested()

            {

            }

            

            internal static readonly Singleton instance = new Singleton();

            }

            }

            

Here, instantiation is triggered by the first reference to the static member of the nested class, which only occurs in Instance. This means the implementation is fully lazy, but has all the performance benefits of the previous ones. Note that although nested classes have access to the enclosing class's private members, the reverse is not true, hence the need for instance to be internal here. That doesn't raise any other problems, though, as the class itself is private. The code is a bit more complicated in order to make the instantiation lazy, however.

Performance vs laziness

In many cases, you won't actually require full laziness - unless your class initialization does something particularly time-consuming, or has some side-effect elsewhere, it's probably fine to leave out the explicit static constructor shown above. This can increase performance as it allows the JIT compiler to make a single check (for instance at the start of a method) to ensure that the type has been initialized, and then assume it from then on. If your singleton instance is referenced within a relatively tight loop, this can make a (relatively) significant performance difference. You should decide whether or not fully lazy instantiation is required, and document this decision appropriately within the class. (See below for more on performance, however.)

Exceptions

Sometimes, you need to do work in a singleton constructor which may throw an exception, but might not be fatal to the whole application. Potentially, your application may be able to fix the problem and want to try again. Using type initializers to construct the singleton becomes problematic at this stage. Different runtimes handle this case differently, but I don't know of any which do the desired thing (running the type initializer again), and even if one did, your code would be broken on other runtimes. To avoid these problems, I'd suggest using the second pattern listed on the page - just use a simple lock, and go through the check each time, building the instance in the method/property if it hasn't already been successfully built.

Thanks to Andriy Tereshchenko for raising this issue.

A word on performance

A lot of the reason for this page stemmed from people trying to be clever, and thus coming up with the double-checked locking algorithm. There is an attitude of locking being expensive which is common and misguided. I've written a very quick benchmark which just acquires singleton instances in a loop a billion ways, trying different variants. It's not terribly scientific, because in real life you may want to know how fast it is if each iteration actually involved a call into a method fetching the singleton, etc. However, it does show an important point. On my laptop, the slowest solution (by a factor of about 5) is the locking one (solution 2). Is that important? Probably not, when you bear in mind that it still managed to acquire the singleton a billion times in under 40 seconds. That means that if you're "only" acquiring the singleton four hundred thousand times per second, the cost of the acquisition is going to be 1% of the performance - so improving it isn't going to do a lot. Now, if you are acquiring the singleton that often - isn't it likely you're using it within a loop? If you care that much about improving the performance a little bit, why not declare a local variable outside the loop, acquire the singleton once and then loop. Bingo, even the slowest implementation becomes easily adequate.

I would be very interested to see a real world application where the difference between using simple locking and using one of the faster solutions actually made a significant performance difference.

Conclusion (modified slightly on January 7th 2006)

There are various different ways of implementing the singleton pattern in C#. A reader has written to me detailing a way he has encapsulated the synchronization aspect, which while I acknowledge may be useful in a few very particular situations (specifically where you want very high performance, and the ability to determine whether or not the singleton has been created, and full laziness regardless of other static members being called). I don't personally see that situation coming up often enough to merit going further with on this page, but please mail me if you're in that situation.

My personal preference is for solution 4: the only time I would normally go away from it is if I needed to be able to call other static methods without triggering initialization, or if I needed to know whether or not the singleton has already been instantiated. I don't remember the last time I was in that situation, assuming I even have. In that case, I'd probably go for solution 2, which is still nice and easy to get right.

Solution 5 is elegant, but trickier than 2 or 4, and as I said above, the benefits it provides seem to only be rarely useful.

(I wouldn't use solution 1 because it's broken, and I wouldn't use solution 3 because it has no benefits over 5.)