本系列的全部源代码及二进制文件可以从这里下载：IocInCSharp.rar

你真的了解Ioc与AOP吗？（1）

你真的了解Ioc与AOP吗？（2）

你真的了解Ioc与AOP吗？（3）

你真的了解Ioc与AOP吗？（4）

你真的了解Ioc与AOP吗？（5）

本部分示例代码请参考"src\Step1"、"src\Step2"目录

你真的了解Ioc与AOP吗？我现在还不是很了解，而且越学习越发现自己了解的很少，Ioc与AOP中蕴涵了大量的能量等待我们去开发。在这个系列中，我仅仅利用Sping.net这个框架向大家展示一下Ioc与AOP的强大功能（呵呵，其实写这段话的目的是因为“文章题目”牛皮吹得有点大了，给自己个台阶下罢了）。

在这个系列中一共包含6个案例，从简单到复杂，也是对问题分解、思考和解决的一个过程，它们分别是：（1）类之间的依赖；（2）接口依赖；（3）基于配置文件和Reflection的工厂模式；（4）使用Spring.net实现Ioc；（5）Romoting；（6）利用Ioc在不动一行代码的情况下实现Remoting。为了更好的理解文中的内容，最好顺序阅读。

作为一个应用系统，代码复用至关重要。如果在你的设计中，类与类存在很强的相互关联，那么你会发现在重用这些组件时就存在很严重的问题。在Step1到Step3-Reflection的例子中，我们试图 利用“针对接口编程”以及自己设计的Ioc对系统进行解耦。在Step3到Step5的例子中，我们将利用Spring.net提供的Ioc框架，轻松完成解耦以及系统改造等工作。

我将使用本页链接到有关Silverlight 2的文章和贴子（包括我写的和别人写的），请经常回来查看新的内容，因为我才开始。

入门教程

• Silverlight 2 初览: 我建议先读这个贴子，如果你正考虑开始Silverlight 2开发的话。该文不仅对Silverlight 2提供的功能做了高层次的描述，还链接到了一个八个贴子的系列教程，该教程对如何建造一个Digg客户端例程做了示范。这些教程贴子对Silverlight 2和WPF开发的概念提供了很好的介绍。

• 使用Expression Blend开发Silverlight 2应用 -- 初览: 我建议下载Expression Blend 2.5 三月份预览版，按本教程贴子的步骤进行。我认为它很好地展示了Expression Blend的一些常见功能，用它建造了一个IM聊天客户端例程。

• Unit Testing with Silverlight 2: Silverlight开发团队的Jeff Wilcox有一篇精彩贴子，讨论如何使用Silverlight SDK中的单元测试框架单元测试Silverlight 2应用。

入门讲座

• Building Rich Internet Applications with Silverlight (Part 1 and 2): Joe Stegman和Mike Harsh在MIX 08上做了这分成2个部分的讲座， 讨论如何使用Silverlight建造应用。你可以使用上面的链接观看他们讲座的录像和下载相关讲义和示范例程。

• Creating Rich, Dynamic User Interfaces with Silverlight 2 Controls: Karen Corby在MIX 08上有个极棒的讲座，很好地解释了样式，控件模板，用户控件等等。你可以在这里运行和下载她完整的FlickR应用。

• 我的Silverlight入门讲座: 你可以下载我最近在亚利桑那做的“Silverlight 2入门”讲座的讲义和示范例程，请随意在你自己的讲座中重用这些讲义。

文档链接

• Silverlight 2 QuickStart Tutorials: 这些示范教程在上手Silverlight时会非常有用。

• Silverlight 2 Developer Poster: 下载和打印Silverlight 2开发者海报。

• Silverlight Control Source and Unit Tests: Shawn Burke提供了内置的Silverlight控件的源码以及相关单元测试的链接。

• MSDN Silverlight 2 Beta1 Online Documentation: 这个网页提供了正式的Silverlight 2文档的链接。你可以在这里下载离线版本。

教程和例程

• "How Do I?" with Silverlight: 这个链接连到了含有一堆Silverlight 2录像教程的网页。

• Hard Rock Memorabilia Sample: Vertigo Software公司的Scott Stanfield讨论三月份发布的使用Silverlight 2建造的很酷的Hard Rock Memorabilia网站。

• Using Deep Zoom with Silverlight 2: Jacek Ciereszko有一个很好的博客贴子，描述了如何使用Silverlight 2的 “Deep Zoom”功能实现跟Hard Rock例程类似的图像放大功能。

• Game Programming with Silverlight: Mike Snow正打造一个分成十一个部分的博客系列，讨论如何使用Silverlight开发在线游戏。

• Homepage "Link Cloud" application: Jeff Wilcox讨论他建造的一个很酷的标签云应用。

部署体验

• Providing a Great Silverlight Deployment Experience: Tim Heuer有个很好的贴子，讨论可以为你所用的技术来优化Silverlight安装体验。

• Using Silverlight 2 on a Production Web Server: Brad Abrams有个很好的贴子，讨论在把Silverlight .xap文件拷贝到IIS web服务器时需要注意的几件事情。

控件模板

• Creating a Custom Skin for Silverlight's Button Control: Matt Berseth的一个精彩好贴，讨论Silverlight控件的皮肤和样式功能。

• Writing a Templated Silverlight Control: Shawn Burke有个精彩贴子，详细描述了如何创建定制的Silverlight模板控件。

• Improving Access to Silverlight's Generic.xaml Resources (也阅读 这里的Part 2): David Anson有个很棒的工具，示范如何查看和提取内置Silverlight控件的默认XAML样式。

ListBox和ScrollViewer场景

• Ultimate ListBox and ScrollViewer Frequently Asked Questions Guide: David Anson，Silverlight ListBox和ScrollViewer控件的开发者，编篡了这个很棒的，关于所有这些控件的FAQ以及你可以使用它们的场景。

• Cool (wacky) uses of the ListBox and ScrollViewer controls: David Anson的又一篇精彩贴子，展示了数据和控件模板的灵活性。

DataGrid场景

• Using the Silverlight DataGrid and Defining Columns for a Silverlight DataGrid: Scott Morrison开始了一个精彩贴子系列，描述如何使用新的Silverlight 2 DataGrid控件（他是相关项目的主管，绝对精通！）

• Using Silverlight 2's DataGrid with WCF + LINQ to SQL: 这个15分钟的录像博客示范了如何在服务器上建造一个LINQ to SQL对象模型，然后用WCF将其发布，然后示范了如何建造一个使用了新的Silverlight DataGrid控件的Silverlight客户端，该客户端调用WCF服务获取LINQ to SQL数据，将其绑定到DataGrid上。

• Simple Editing of Web Service Data in a DataGrid: Mike Taulty有一篇好贴，展示如何在服务器上建造WCF服务，然后从Silverlight 2客户端使用它来获取数据，绑定到DataGrid，允许用户更新数据行，添加/删除数据行，然后使用 Silverlight 2 Beta1将数据保存到服务器上。

• Sorting with Silverlight 2's DataGrid Control: Silverlight 2 Beta1中的DataGrid控件还没有内置的列数据排序支持（将在Beta2中提供），但这并没有阻止Matt Berseth！ 在这个贴子里，他展示了如何使用一个定制的header列方法来实现排序。也看一下Matt的 这里的贴子，该文提供了一个DataGrid测试页面，展示了目前DataGrid的若干特性。

Web Services 和 Networking

• Web Services and Silverlight: 这个有用的贴子讨论了如何在Silverlight中使用web服务，并且提供了相关快速入门例程和文档的链接。

• Calling Web Services with Silverlight 2 (Part 1) and (Part 2): Tim Heuer的几篇精彩贴子，讨论如何使用Silverlight调用web服务。

Video场景

• Encoding Video for Microsoft Silverlight Delivery: Ben Waggoner在MIX 08上的讲座，讨论编码Silverlight录像的最佳实践。

Accessibility 和 508相容性

• Accessibility in Silverlight 2: Silverlight开发团队的Mark Rideout讨论 Silverlight 2 中的accessibility支持，以及如何使用Silverlight建造与section 508相容的accessible方案。

希望本文对你有所帮助，

Scott

This article was written by José M. Aguilar in Spanish on his excellent blog Variable Not Found, and was translated, edited and republished here by Timm Martin (and Google Translator) with permission from Mr. Aguilar.

Following are 13 tips on how to comment your source code so that it is easier to understand and maintain over time.

1. Comment each level

Comment each code block, using a uniform approach for each level.  For example:

• For each class, include a brief description, author and date of last modification
• For each method, include a description of its purpose, functions, parameters and results

Adopting comment standards is important when working with a team.  Of course, it is acceptable and even advisable to use comment conventions and tools (such as XML in C# or Javadoc for Java) to facilitate this task.

2. Use paragraph comments

Break code blocks into multiple "paragraphs" that each perform a single task, then add a comment at the beginning of each block to instruct the reader on what is about to happen.

// Check that all data records
// are correct
foreach (Record record in records)
{
    if (rec.checkStatus()==Status.OK)
    {
        . . .
    }
}
// Now we begin to perform
// transactions
Context ctx = new ApplicationContext();
ctx.BeginTransaction();
. . .

 

3. Align comments in consecutive lines

For multiple lines of code with trailing comments, align the comments so they will be easy to read.

const MAX_ITEMS = 10; // maximum number of packets
const MASK = 0x1F;    // mask bit TCP

Some developers use tabs to align comments, while others use spaces.  Because tab stops can vary among editors and IDEs, the best approach is to use spaces.

4. Don't insult the reader's intelligence

Avoid obvious comments such as:

if (a == 5)      // if a equals 5
    counter = 0; // set the counter to zero

This wastes your time writing needless comments and distracts the reader with details that can be easily deduced from the code.

5. Be polite

Avoid rude comments like, "Notice the stupid user has entered a negative number," or "This fixes the side effect produced by the pathetically inept implementation of the initial developer."  Such comments do not reflect well upon their author, and you never know who may read these comments in the future: your boss, a customer, or the pathetically inept developer you just insulted.

6. Get to the point

Don't write more in comments than is needed to convey the idea.  Avoid ASCII art, jokes, poetry and hyperverbosity.  In short, keep the comments simple and direct.

7. Use a consistent style

Some people believe that comments should be written so that non-programmers can understand them.  Others believe that comments should be directed at developers only.  In any event, as stated in Successful Strategies for Commenting Code, what matters is that comments are consistent and always targeted to the same audience.  Personally, I doubt many non-developers will be reading code, so comments should target other developers.

8. Use special tags for internal use

When working on code as a team, adopt a consistent set of tags to communicate among programmers.  For example, many teams use a "TODO:" tag to indicate a section of code that requires additional work:

int Estimate(int x, int y)
{
    // TODO: implement the calculations
    return 0;
}

Tag comments don't explain code; rather they seek attention or deliver a message.  But if you use this technique, remember to follow up and actually do what the message is asking.

9. Comment code while writing it

Add comments while you write code and it's fresh in your memory.  If you leave comments until the end, it will take you twice as long, if you do it at all.  "I have no time to comment," "I'm in a hurry," and "The project is delayed" are all simply excuses to avoid documenting your code.  Some developers believe you should write comments before code as a way to plan out your ultimate solution.  For example:

public void ProcessOrder() 
{
    // Make sure the products are available
    // Check that the customer is valid
    // Send the order to the store
    // Generate bill
}

10. Write comments as if they were for you (in fact, they are)

When it comes to commenting code, think not only about the developers who will maintain your code in the future, but also think about yourself.  In the words of the great Phil Haack:

"As soon as a line of code is laid on the screen, you’re in maintenance mode on that piece of code."

As a result, we ourselves will be the first beneficiaries (or victims) of our good (or bad) comments.

11. Update comments when you update the code

There is no point in commenting correctly on code if the comments are not changed with the code.  Both code and comments must move in parallel, otherwise the comments will actually make life more difficult for developers who maintain your code.  Pay special attention to refactoring tools that automatically update code but leave comments unchanged and hence obsolete in the same instant.

12. The golden rule of comments: readable code

One of the basic principles for many developers: Let your code speak for itself.  Although one suspects this movement is led by programmers who do not like to write comments, it is true that self-explanatory code can go a long way toward making code that's easier to understand and can even render comments unnecessary.  For example, the code in my Fluid Interfaces article shows how clear self-explanatory code can be:

Calculator calc = new Calculator();
calc.Set(0);
calc.Add(10);
calc.Multiply(2);
calc.Subtract(4);
Console.WriteLine( "Result: {0}", calc.Get() );

In this example, comments are not needed and would likely violate tip #4.  To facilitate readable code, you might consider using proper names (as described in the classic Ottinger's Rules), ensure correct indentation, and adopt coding style guides.  Failure to comply with this tip may result in comments that seem to apologize for bad code.

13. Share these tips with your colleagues

Although tip #10 shows how we ourselves benefit immediately from good comments, these tips will benefit all developers, especially in the context of team working together.  Therefore, feel free to share these commenting tips with your colleagues to create code that is easier to understand and maintain.

如何实现可插拔的windows服务
关于windows服务的创建相关资源很多，园子里面也有很多这样的文章。
整理了一下相关blog如下，
http://www.cnblogs.com/wuxilin/archive/2006/06/04/416838.html
http://www.cnblogs.com/wujm/archive/2005/05/12/154369.html
http://www.cnblogs.com/caca/archive/2005/02/25/109028.html
http://www.cnblogs.com/laiwen/archive/2005/08/21/219590.html

归纳一下步骤大概如下：
1.创建服务:
1.1我们应该创建windows服务类型的project，IDE会自动从serviceBase类继承一个类出来，在这个类里面有on_star和on_stop两个方法，可以在里面写入启动逻辑和停止逻辑
在设计视图下我们可以修改service的属性
Autolog                 是否自动写入系统的日志文件
CanHandlePowerEvent     服务时候接受电源事件
CanPauseAndContinue     服务是否接受暂停或继续运行的请求
CanShutdown             服务是否在运行它的计算机关闭时收到通知，以便能够调用 OnShutDown 过程
CanStop                 服务是否接受停止运行的请求
ServiceName             服务名
1.2选择服务组件,并切换到设计模式,右键->Add Installer,生成安装文件。安装文件中的属性修改可以参考下面的内容：
projectInstall参数修改Account(指定用户还是使用本地系统用户)
ServiceInstall参数修改：
描述名：Description，
显示名：DisplayName,
ServiName:服务名，要和刚才建立的服务名一一对应才行
StartType：(Manual:服务安装后，必须手动启动.Automatic:每次计算机重新启动时，服务都会自动启动;Disabled:服务无法启动)

2安装
安装服务要使用微软提供的工具InstallUtil，这个工具在c:/windows/wicrosoft.net/framework/[version]中
使用InstallUtil 安装，使用InstallUtil /u 反安装服务

如果还有什么可以参考刚才说的那几个blog，ok一切都很简单。但是如果要做为一个企业级的应用，往往会有别的场景需求，下面说一下我曾碰到的场景要求
1.我们的windows服务可能不止满足一种业务逻辑，比如：如果你的机器安装了oracle的话，就会有OracleService服务，我们启动数据库的时候可以只是启动tns服务和OracleService服务就可以了，但是实际上启动OracleService服务的同时会启动好几个服务，例如:DBWR(数据文件写入),LGWR(日志文件写入),SMON(系统监护),PMON(用户进程监),CKPT(检查点,同步数据文件,日志文件,控制文件等)。有时为了性能的考虑，一个服务也可能要多线程的运行业务逻辑。比如一个导入文件的数据接口服务，如果数据量非常大就要这样考虑。一般如果执行多个任务，可以有两种方法：1.开多个线程；2.在一个线程中顺序进行(可以加上时间控制)。我觉得这里最灵活的方法是用.net本省的多线程支持来解决。
2.要能在不改变系统结构的情况下，可以非常快速的支持新的服务要求。这说明我们在onstar方法中不能写入相关类的处理逻辑，必须要用某种方法解耦才行。

实现方法：
参考下面的类图

servcive类和具体的业务实现类解耦，我们可以使用工厂模式生成业务逻辑类，每个业务逻辑类启动在一个新的线程中，在.net中工厂模式可以用反射非常方便的实现，这块代码如下：

typeInfo = node.Attributes["type"].Value;
                    Type type = Type.GetType(typeInfo);
                    IService instance = (IService)Activator.CreateInstance(type);
                    //初始化服务
                    instance.Initialize(node);
                    instanceArray.Add(instance);

                    //在新线程中运行服务,每个服务使用相同的安全上下文
                    ThreadStart ts = new ThreadStart(instance.Start);
                    Thread t = new Thread(ts);
                    t.Start();

从配置文件中读出需要加载的业务逻辑类，实例化后用ThreadStart调用其中的Start方法，启动新线程。这里对配置文件的读取如果要求比较高可以采用Enterprise Libary的Login block来做。
在OnStop方法中调用每个类的Stop方法，如果想对每个Stop方法异步调用，可以用delegate封装接口的Stop方法用
BeginInvoke方法实现异步调用

这样，整个windows服务就实现了，这里还有个额外的好处是可以热部署，即不需要删除已经部署的windows服务，将新的DLL覆盖将以前的DLL覆盖,修改*.exe.config文件并重新启动就可以了。其实我觉得停止服务，重新编译部署后在启动服务花费的时间可能比这样还少些。

关于调试：
windows服务常用的调试方法是用调试－>附加到进程的方法。
选择显示所有用户进程，我们已经部署并启动的windows服务进程就会出现，并跳到我们设置好的断点处。但是这样对service中的onstart部分调试比较麻烦。我还是推荐创建一个porjec做为调试用，这里面可以写onstart部分的代码，代码不多，非常方便。大家就可以象调试普通windows程序一样调试这windows服务代码了

扩展名称通常包括命名空间 URI（或关联的前缀）、冒号 (:) 和本地部分。例如，b:author 是扩展名称，其中 b 是命名空间 URI 前缀，author 是本地部分。所以，对此节点应用 local-name() 函数将返回 author。如果节点没有扩展名称，例如 author，对此节点应用 local-name() 函数将返回原始节点名称，即 author。

注意，要用1的namespaceManager对象。

3、获取Workbook中Name等于"Sheet1"的Worksheet节点中，Table的DefaultColumnWidth属性值。

注意，要用1的namespaceManager对象。

1、程式启动时，计算器在刷新时间。
2、点击“Go”，按钮无效状态，计算停止。
3、5秒后按钮恢复状态，计算重新启动。
4、2-3之间UI不能出现阻塞，即是要用多线程。



程序：
1、定义界面接口IForm

2、异步运行程式

3、界面代码

如何：对 Windows 窗体控件进行线程安全调用”即可得到答案。

如下修改界面代码即可

public void EnableButton()
        {
            //使用控件的InvokeRequired判断执行Invoke
            if (this.btn.InvokeRequired)
            {
                this.Invoke(new AscyUpdateControl(EnableButton));
            }
            else
            {
                this.btn.Enabled = true;
            }
        }

        public void DisableButton()
        {
            if (this.btn.InvokeRequired)
            {
                this.Invoke(new AscyUpdateControl(DisableButton));
            }
            else
            {
                this.btn.Enabled = false;
            }
        }

        public void StopTimer()
        {
            //如没有InvokeRequired属性，简写如下代码即可
            this.Invoke(new AscyUpdateControl(delegate
            {
                this.timer1.Stop();
            }));
        }

        public void RecoverTimer()
        {
            this.Invoke(new AscyUpdateControl(delegate
            {
                this.timer1.Start();
            }));
        }

 

代码

KiMoGiGi 2007-12-12 23:55 发表评论

]]>

Introduction

The Model View Controller (MVC) architectural pattern separates an application into three main components: the model, the view, and the controller. The ASP.NET MVC framework provides an alternative to the ASP.NET Web-forms pattern for creating MVC-based Web applications. The ASP.NET MVC framework is a lightweight, highly testable presentation framework that (as with Web-forms-based applications) is integrated with existing ASP.NET features, such as master pages and membership-based authentication. The MVC framework is defined in the System.Web.Mvc namespace and is a fundamental, supported part of the System.Web namespace.

MVC is a standard design pattern that many developers are familiar with. Some types of Web applications will benefit from the MVC framework. Others will continue to use traditional ASP.NET application pattern that is based on Web forms and postbacks. Other types of Web applications will combine the two approaches; neither approach precludes the other.

The MVC framework does not use view state or server-based forms. This makes it ideal for developers who want full control over the behavior of an application.

On the other hand, Web forms-based applications support an event model that preserves state over HTTP, which benefits line-of-business Web application development. The Web-forms-based application provides dozens of events that are supported in hundreds of server controls. MVC uses a Front Controller pattern that enables you design an application that completely separates the tasks of presentation, business logic, and data access, and that supports a rich routing infrastructure. Web forms applications use a page-controller pattern that adds functionality to individual pages. These two patterns can be mixed as needed.

The MVC components are as follows:

• Models - Model objects are the parts of your application that implement the domain logic. Often, model objects also retrieve and store model state in a database. For example, a Product object might retrieve information from a database, operate on it, and then write updated information back to a Products table in SQL Server.

  note

  In smaller applications, the model is often a conceptual separation rather than a physical one. For example, if the application only reads a data set and sends it to the view, the application does not have a physical model layer and associated classes. In that case, the data set takes on the role of a model object.

• Views - Views are the components that display the application's user interface (UI). Typically, this UI is created from the model data. An example would be an edit view of a Products table that displays text boxes, drop-down lists, and check boxes based on the current state of a Product object.

• Controllers - Controllers are the components that handle user interaction, manipulate the model, and ultimately select a view to render that displays UI. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction. For example, the controller handles query-string values, and passes these values to the model, which in turn queries the database by using the values.

The MVC pattern helps you to create applications that separate the different aspects of the application (input logic, business logic, and UI logic), while providing a loose coupling between these elements. The pattern specifies where each kind of logic should exist in the application. The UI logic belongs in the view. Input logic belongs in the controller. Business logic belongs in the model. This separation helps you manage complexity when you build an application, because it enables you to focus on one aspect of the implementation at a time. For example, you can focus on the view without depending on the business logic.

In addition to managing complexity, the MVC pattern makes testing applications easier than testing a traditional ASP.NET Web application. For example, in a traditional ASP.NET Web application, a single class is used both to display output and to respond to user input. Writing automated tests for traditional ASP.NET applications can be complex, because to test an individual page, you must instantiate the page class, all its child controls, and additional dependent classes in the application. Because so many classes are instantiated to run the page, it can be hard to write tests that focus exclusively on individual portions of the application. Tests for traditional ASP.NET applications can therefore be more difficult to implement than test within an MVC application. Moreover, tests within a traditional ASP.NET application require a Web server. The MVC framework decouples the components and makes heavy use of interfaces, which makes it possible to test individual components in isolation from the rest of the framework.

The loose coupling between the three main components of an MVC application also promotes parallel development. For instance, one developer can work on the view, a second developer can work on the controller logic, and a third developer can focus on the business logic in the model.

Features of the ASP.NET MVC Framework

The ASP.NET MVC framework provides the following features:

• Separation of application tasks (input logic, business logic, and UI logic), testability, and test-driven development (TDD) by default. All core contracts within the MVC framework are interface-based and can be tested by using mock objects. You can unit-test the application without having to run the controllers in an ASP.NET process, which makes unit testing fast and flexible. You can use any unit-testing framework that is compatible with the .NET Framework.

• An extensible and pluggable framework. The components of the ASP.NET MVC framework are designed so that they can be easily replaced or customized. You can plug in your own view engine, URL routing policy, action-method parameter serialization, and other components. The ASP.NET MVC framework also supports using existing dependency injection and Inversion of Control (IOC) container models.

• A powerful URL-mapping component that lets you build applications that have comprehensible and searchable URLs. URLs do not have to include file-name extensions, and are designed to support URL naming patterns that work well for search engine optimization (SEO) and representational state transfer (REST) addressing. For example, you could map the /products/edit/4 URL to the Edit action of a ProductsController class in your project, or map the /Blogs/YourSite/10-10-2007/SomeTopic/ URL to a DisplayPost action of a BlogEngineController class. URLs do not have to reference file names.

• Support for using the markup in existing ASP.NET pages (.aspx files), user controls (.ascx files), and master pages (.master files) markup files as view templates. You can use existing ASP.NET features with the ASP.NET MVC framework, such as nested master pages, in-line expressions (<%= %>), declarative server controls, templates, data-binding, localization, and so on.

• Support for existing ASP.NET features. ASP.NET MVC lets you use features such as forms and Windows authentication, URL authorization, membership and roles, output and data caching, session and profile state management, health monitoring, configuration system, the provider architecture, and other areas of ASP.NET.

Background

In an ASP.NET Web Site, URLs typically map to files stored on disk (typically .aspx files). These .aspx files include code or markup that is processed in order to respond to the request.

The ASP.NET MVC framework maps URLs to server code in a different way. Instead of mapping URLs to ASP.NET pages or handlers, the framework maps URLs directly to controller classes. Controller classes handle incoming requests, such as user input and interactions, and also execute appropriate application and data logic based on user input. A controller class typically calls a separate view component that generates the HTML output as the response.

The ASP.NET MVC framework separates the model, view, and controller components. The model component maintains state by typically persisting data inside a database. The view component is selected by the controller and renders the appropriate UI. By default, the ASP.NET MVC framework uses the existing ASP.NET page (.aspx), master page (.master), and user control (.ascx) types for rendering to the browser. The controller component locates the appropriate action method in the controller, gets the values to use as the action method's arguments, handles all errors that might occur during the execution of the action, and renders the requested view. Each set of components exists in a separate subdirectory of an MVC Web application project.

URL Mapping

The ASP.NET MVC framework includes a URL-mapping engine that provides flexibility for mapping URLs to controller classes. You can use the mapping engine to define routing rules that the ASP.NET MVC framework uses to evaluate incoming URLs and to select a controller to execute. You can also have the routing engine automatically parse variables defined in the URL and have the ASP.NET MVC framework pass these to the controller as parameter arguments.

The MVC Framework and Postbacks

ASP.NET MVC framework does not use the traditional ASP.NET postback model for interactions with the server. Instead, all end-user interactions are routed to a controller class. This maintains separation between UI logic and business logic and helps testability. As a result, ASP.NET view state and ASP.NET page life-cycle events are not integrated with MVC-based views.

Creating an ASP.NET MVC Application

The ASP.NET MVC framework includes Visual Studio project templates that let you create Web applications that are structured to support the MVC pattern. The MVC Web Application template is used to create a new Web application that is configured with the subdirectories, templates, and configuration-file entries that are required for an ASP.NET MVC application.

By default, when you create a new Web application by using this template, Visual Studio creates a solution and adds two projects to the solution. The first project is a Web project where you can implement your application. The second project is a testing project that you can write unit tests for your MVC components.

You can use any unit-testing framework that is compatible with the .NET Framework to test ASP.NET MVC applications. Visual Studio 2008 Professional includes built-in testing project support for MSTest.

Understanding Web Application MVC Project Structure

When you create an ASP.NET MVC Web application project, MVC components are separated based on the following project folders:

• Views folder. The Views folder is the recommended location for views. The views use .aspx, .ascx, and .master files, as well as any other files that are related to rendering views. The Views directory contains a folder for each controller that is named with the controller prefix. When loading a view, by default the ASP.NET MVC framework will look for an .aspx file with the requested view name in the Views\controllerName folder. There is also a default directory named Common that does not correspond to any controller. This is a useful location to put master pages, scripts, CSS files, and other files that are used when rendering a view.

• Controller folder. The Controllers folder is the recommended location for controllers.

• Model folder. The Models folder is the recommended location for classes that represent the application model for your MVC Web application. Typically, this includes code that defines the logic for interaction with the data store.

• App_Data. The physical store for data. This folder has the same role as it does in Web-forms based ASP.NET Web applications.

In addition to the folders listed previously, a MVC Web application uses the following application elements:

• Global.asax and Global.asax.cs (or Global.asax.vb in Visual Basic). In Global.asax.cs, routes are initialized in the Application_Start method. The following example shows a typical Global.asax file that includes default routing logic.

  public class Global : System.Web.HttpApplication {
      protected void Application_Start(object sender, EventArgs e) {
      RouteTable.Routes.Add(new Route {
      Url = "[controller]/[action]/[id]",
      Defaults = new { action = "Index", id = (string)null },
      RouteHandler = typeof(MvcRouteHandler)
      });
      }
      }

• Configuration. The MVC Web application Web.config file registers HTTP handlers and HTTP modules. The httpHandlers section registers the MvcHandler class, which routes requests to the appropriate controller. The following example shows the httpHandlers section for an ASP.NET MVC application.

  <httpHandlers>
      <add verb="*" path="*.mvc" type="System.Web.Mvc.MvcHandler,
      System.Web.Extensions, Version=3.6.0.0, Culture=neutral,
      PublicKeyToken=31BF3856AD364E35"/>
      </httpHandlers>

  The httpModules section registers the UrlRoutingModule class, which parses the URL and routes requests to the appropriate handler. This entry enables the application to host MVC and non-MVC handlers in the same project. The following example shows the httpModules section for an ASP.NET MVC application.

  <httpModules>
      <add name="UrlRoutingModule"
      type="System.Web.Mvc.UrlRoutingModule,
      System.Web.Extensions, Version=3.6.0.0, Culture=neutral,
      PublicKeyToken=31BF3856AD364E35" />
      </httpModules>

When you create an MVC Web application project, the solution includes a Test project. You can create tests by using the MVC templates and create mock implementations of the intrinsic interfaces.

Understanding the MVC Project Execution Process

Requests to a Web site that is built by using the MVC framework are routed through an ASP.NET HTTP module and to an HTTP handler.

The module and handler are the entry points to the ASP.NET MVC framework and perform the following actions:

• Select the appropriate controller in an MVC Web application.

• Obtain a specific controller instance.

• Call the controller's Execute method.

The following table lists the stages of execution for an MVC Web project:

Example

The following code shows the default structure that is created by Visual Studio when you create a new MVC Web application.

This topic is ASP.NET 3.5 Extensions Preview pre-release documentation and is unsupported by Microsoft. Blank topics are included as placeholders and existing content is subject to change in future releases. To provide feedback or ask questions about the release, please go to the ASP.NET 3.5 Extensions Preview forums.

摘自：http://www.yoda.arachsys.com/csharp/stringbuilder.html

Concatenating Strings Efficiently

One of the first pieces of efficiency advice most .NET developers learn is "use StringBuilder to concatenate strings". A little bit like "exceptions are expensive" this is a misunderstood piece of received wisdom. (Fortunately it's not nearly as harmful as the exception performance myth, but it comes up about as often...)

Before reading the rest of this page, you should be aware of the basics of the String type. For the sake of readability, I'll stick to "string" rather than "String" or "string" from here onwards. Please let me know if you find this confusing, and I'll change it.

I've included this in my list of general framework articles rather than in the list of C#-specific articles because I suspect every language targetting .NET is likely to use the same way of concatenating strings under the hood.

The Problem We're Trying To Avoid

There is a very real problem that this wisdom correctly addresses - that of building a load of strings (usually of increasing size) which are never used apart from contributing to the creation of other strings. Here's an example:

using System;
            public class Test
            {
            static void Main()
            {
            DateTime start = DateTime.Now;
            string x = "";
            for (int i=0; i < 100000; i++)
            {
            x += "!";
            }
            DateTime end = DateTime.Now;
            Console.WriteLine ("Time taken: {0}", end-start);
            }
            }
            

On my (fairly fast) laptop, that takes nearly 10 seconds. Double the number of iterations, and it takes over a minute. The results are slightly better on .NET 2.0 beta 2, but not hugely. The problem is that strings are immutable - just because we're using "+=" here doesn't mean the runtime actually appends to the end of the existing string. In fact, x += "!"; is absolutely equivalent to x = x+"!";. The concatenation here is creating an entirely new string, allocating enough memory for everything, copying all the data from the existing value of x and then copying the data from the string being appended ("!"). As the string grows, the amount of data it has to copy each time grows too, which is why the time taken didn't just double when I doubled the number of iterations.

This is clearly inefficient. If someone asked you to add something to a shopping list, you wouldn't write a new copy of the shopping list first, would you? Enter StringBuilder...

The StringBuilder Solution

Here is an equivalent (in terms of the final value of x) program, which is much, much faster:

using System;
            using System.Text;
            public class Test
            {
            static void Main()
            {
            DateTime start = DateTime.Now;
            StringBuilder builder = new StringBuilder();
            for (int i=0; i < 100000; i++)
            {
            builder.Append("!");
            }
            string x = builder.ToString();
            DateTime end = DateTime.Now;
            Console.WriteLine ("Time taken: {0}", end-start);
            }
            }
            

On my laptop, this executes too fast for the rudimentary timing mechanism I'm using to give me any sensible results. Changing to a million iterations (i.e. ten times what the first program took nearly ten seconds to do), it takes about 30-40ms. The time taken is roughly linear in the number of iterations (i.e. double the iterations and it takes twice as long). It does this by avoiding unnecessary copying - only the data we're actually appending gets copied. StringBuilder maintains an internal buffer and appends to that, only copying its buffer when there isn't room for any more data. (In fact, the internal buffer is just a string - strings are immutable from a public interface perspective, but not from within the mscorlib assembly.) We could make the above code even more efficient by passing the final size of the string (which we happen to know in this case) to the constructor of StringBuilder to make it use a buffer of the right size to start with - then there'd be no unnecessary copying at all. Unless you're in a situation where you have that information readily to hand though, it's usually not worth worrying about - StringBuilder doubles its buffer size when it runs out of room, so it doesn't end up copying the data very many times anyway.

So I Should Use StringBuilder Everywhere, Right?

No, quite simply. The above is an explanation of why the received wisdom of "use StringBuilder for concatenation" is right some of the time. However, many people take it at face value without understanding the reasoning behind it. They start turning code like this:

string name = firstName + " " + lastName;
            Person person = new Person (name);
            

into code like this:

// Bad code! Do not use!
            StringBuilder builder = new StringBuilder();
            builder.Append (firstName);
            builder.Append (" ");
            builder.Append (lastName);
            string name = builder.ToString();
            Person person = new Person (name);
            

All that in the name of inefficiency. Now, on a broader point, even if the second version were more efficient than the first, it probably wouldn't be significantly more efficient - unless that code ended up being called vast, vast numbers of times, the amount of time spent in the concatenation is likely to be tiny. Making something less readable (and I think you'll agree the second version takes far longer to understand) for a small performance gain is a really bad idea in the first place.

However, the second version is actually less efficient than the first! Not much less efficient - and if the second version were more readable, I'd go with it for the reasons above - but when the entire point of using StringBuilder is to improve efficiency, using the above is just plain nuts.

The first version (assuming that firstName and lastName are real variables, and not constants - I'll come onto that later) compiles to a call to String.Concat, like this:

string name = String.Concat (firstName, " ", lastName);
            Person person = new Person (name);
            

String.Concat takes a bunch of strings (or objects) and concatenates them together, plain and simple. There are various overloads - some take strings, some take objects (which are just converted into strings), some take arrays of objects or arrays of strings. They all do the same thing though. Now, String.Concat can work out the lengths of all the strings involved before it concatenates them together (at least if you pass it strings - if you pass it objects, it needs to create temporary strings and then concatenate those together). This means that no extra copying is involved - the data is copied once into the new string, which is of exactly the right length.

Compare this with the StringBuilder version. It doesn't know at construction time how big to make the buffer (because we haven't told it - doing so would make the code even less readable). That means it may have to copy the buffer, and it's likely to end up with a buffer which is actually larger than it needs to be. Oh, and there's the overhead of an extra object (the StringBuilder itself). Remind me why this was meant to be a good idea?

The important difference between this example and the previous one is that we can easily present all the strings which need to be concatenated together in one call to String.Concat. That means that no intermediate strings are needed. StringBuilder is efficient in the first example because it acts as a container for the intermediate result without having to copy that result each time - when there's no intermediate result anyway, it has no advantage.

Constants

Things get even crazier when it comes to string constants (literals, const string members). What do you suppose string x = "hello" + " " + "there"; is compiled to? It would be reasonable to expect it to be another call to String.Concat - but it isn't. It's actually compiled to the exact same code as string x = "hello there";. The compiler knows that all the parts are constant, so it does all the concatenation at compile time, storing the full string in the compiled code. Converting that to use StringBuilder is inefficient in both memory and speed, as well as reducing readability.

Rules Of Thumb

So, when should you use StringBuilder, and when should you use the string concatenation operators?

• Definitely use StringBuilder when you're concatenating in a non-trivial loop - especially if you don't know for sure (at compile time) how many iterations you'll make through the loop. For example, reading a file a character at a time, building up a string as you go using the += operator is potentially performance suicide.
• Definitely use the concatenation operator when you can (readably) specify everything which needs to be concatenated in one statement. (If you have an array of things to concatenate, consider calling String.Concat explicitly - or String.Join if you need a delimiter.)
• Don't be afraid to break literals up into several concatenated bits - the result will be the same. You can aid readability by breaking a long literal into several lines, for instance, with no harm to performance.
• If you need the intermediate results of the concatenation for something other than feeding the next iteration of concatenation, StringBuilder isn't going to help you. For instance, if you build up a full name from a first name and a last name, and then add a third piece of information (the nickname, maybe) to the end, you'll only benefit from using StringBuilder if you don't need the (first name + last name) string for other purpose (as we do in the example which creates a Person object).
• If you just have a few concatenations to do, and you really want to do them in separate statements, it doesn't really matter which way you go. Which way is more efficient will depend on the number of concatenations the sizes of string involved, and what order they're concatenated in. If you really believe that piece of code to be a performance bottleneck, profile or benchmark it both ways.

2、.NET Delegates: A C# Bedtime Story
An exploratory story of delegates and events for C# programmers told in the style of a bedtime story.
http://www.codeproject.com/csharp/delegate_bedtime.asp

3、Dependency Injection for Loose Coupling
This article describes the use of Dependency Injection, or Inversion-of-Control, to promote loose coupling and convenient unit testing.
http://www.codeproject.com/cs/design/DependencyInjection.asp
我的翻译：[2007-11-26]使用依赖注入解耦

Events and Delegates simplified
This article shows you how to design events for your classes.
http://www.codeproject.com/csharp/events.asp
我的翻译：[2007-11-19]事件和委托的简单说明

ASP.NET Best Practices for High Performance Applications
This article lists the techniques that you can use to maximize the performance of your ASP.NET applications. It provides common issues, design guidelines, and coding tips to build optimal and robust solutions.
http://www.codeproject.com/aspnet/ASPNET_Best_Practices.asp

• Download MVPSampleApp.zip - 673.2 KB
• Download SQL2000SampleDb.zip - 1,177.7 KB

Introduction

I have been using the model-view-presenter pattern in my ASP.NET web applications for a little over a year now. I was first introduced to MVP in a smart-client application using an event-driven implementation well before applying it in ASP.NET. After spending some time in a thick client environment, I found that applying MVP to the web reveals a new set of problems that need to be addressed. This article will describe these issues and provide an implementation for ASP.NET that I feel maximizes usability and testability.

What this article will do is briefly explain the basics of the pattern and provide three implementations of MVP for ASP.NET. I provide three implementations to allow the reader to see how the pattern can vary, and how the roles for the ASPX page, ASCX user control, and Presenter are defined in each. There is no one correct implementation of MVP in ASP.NET. Whichever implementation is used is really just a matter of personal preference and theoretical debate.

Model-View-Presenter in ASP.NET: Setting the Stage

By default, ASP.NET implements a Page Controller pattern that does not promote good separation of concerns nor testability. The dependency on the ASP.NET runtime makes testing of the implementation difficult without generating testing scenarios that are impractical. Since unit testing of view specific pages is difficult, we look for patterns that promote testability. MVP is such a pattern.

Model-view-presenter is a design pattern that aims to increase separation of concerns and testability. Its primary goal is to separate view specific logic from domain/business logic. As we design object-oriented applications, we desire objects that are loosely coupled and can be easily reused. In order to do so, we need to build classes and layers that are specific to certain tasks, such as view, presentation, service, and data access to name a few. In ASP.NET, it is too easy to add domain or business logic to our ASPX page or ASCX user control classes, creating tightly coupled classes that become difficult to reuse and test. MVP seeks to separate view-specific logic from domain/business logic by using a presentation layer.

The secondary goal of MVP is to improve testability of the view. It is difficult to write a unit test for a class that is dependent upon Session or ViewState, Ajax, Html or web controls, and domain/business objects. Instead, we leave that view-specific logic in the ASPX/ASCX classes and pull presentation and domain/business logic out of the view and put them in their appropriate classes. In MVP, the presenter acts as a mediator between the view and our domain/business logic.

Martin Fowler has split the MVP pattern into two new patterns, Supervising Controller and Passive View. Unlike a true MVC (model-view-controller) framework that enforces a strict separation of the view layer from the presentation (controller), in ASP.NET, this separation is not enforced by default. Because of this, it is difficult to enforce any one implementation of MVP without conscientious effort on the part of the developer, and the grey area between implementing a Supervising Controller and a Passive View widens. As a rule of thumb when creating my presenters, I try and pull as much logic as possible out of the view that I want under test, and put that into the presenter. I let the view handle view-specific logic such as JavaScript, HTML and WebControls, and Ajax frameworks. Since there is still some logic in my view, I tend to classify this as Supervising Controller versus Passive View, and after several sleepless nights debating this in my head, I am happy with Supervising Controller in ASP.NET.

If you need a more detailed introduction beyond what is mentioned above, you may find these links helpful.
GUI Architectures
Supervising Controller
Passive View
Presenter First
Model View Presenter with ASP.NET
ASP.NET Supervising Controller (Model View Presenter) From Schematic To Unit Tests to Code

Different Implementations of MVP in ASP.NET

While implementing MVP in ASP.NET, my designs have followed a few different schools of thought. One such approach was detailed by Billy McCafferty and another by Phil Haack. Since my introduction to MVP was event-driven in a windows application, I applied the event-driven approach that was most familiar to me. The stateless nature of the web was the first obstacle I found I needed to overcome. In ASP.NET, we recreate our MVP relationship with each trip to the server. Persisting state and referencing "Page.IsPostBack" becomes necessary. The sample application and the code snippets below illustrate how we recreate our presenter and pass the IsPostBack value to manage this difficulty. What I have discovered with the MVP pattern is that it can have many variations in ASP.NET, and choosing which one to implement is really a matter of preference. My preferred implementation contains characteristics of some of the authors mentioned above as well as what I have discovered for myself over the past year.

The next section will be divided up into three parts, one for each implementation. I will start with my original introduction to MVP in ASP.NET, then move on to my more familiar event-driven approach. Finally, I will provide a third implementation that I feel provides greater reusability. The sample application I am including with this article has basic examples of each implementation. Each section will describe which modules in the sample app correspond. The code snippets I am providing below are extremely simplistic and are not complete. They are thorough enough to illustrate their points.

The First Implementation

The first implementation is Billy McCafferty's. It introduces the role of the "view initializer and page redirector" to the ASPX page. The view is the ASCX user control, and the presenter only knows about the interface describing the view. The ASPX page is responsible for instantiating the presenter and passing it the view and any model objects the presenter requires. It then attaches the presenter to the view, so the view may reference the presenter when necessary. Lastly, it calls "InitView" on the presenter to simulate the Page.IsPostBack event in ASP.NET.

This example is implemented as the "Product" module in the sample application.

Collapse

Note: The code below is used to highlight the main points of this design. Please see the sample application for a working model.
The Presenter
public class Presenter
{
public Presenter(IView view, IModel model)
{
this.view = view;
this.model = model;
}
public void InitView(bool isPostBack)
{
if(!isPostBack)
{
view.SetProducts(model.GetProducts());
}
}
public void SaveProducts(IList<IProduct> products)
{
model.SaveProducts(products);
}
}
The ASPX Page: The Starting Point
The ASPX HTML references the ASCX user control, and in code behind we have this.
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
presenter = new Presenter(view,model;
view.AttachPresenter(presenter);
presenter.InitView(Page.IsPostBack);
}
The ASCX User Control
public void AttachPresenter(Presenter presenter)
{
this.presenter = presenter;
}
public void SetProducts(IList<IProduct> products)
{
// bind products to view
}
The View Interface
public interface IView
{
void AttachPresenter(Presenter presenter);
void SetProducts(IList<IProduct> products);
}

The Second Implementation

The second implementation is an event-driven approach. It uses the "view initializer and page redirector" role for the ASPX page just as the first. The ASCX user control implements a view interface that declares events that will be raised to a presenter. The view knows nothing about the presenter; it only knows how to raise events. The ASPX page initializes the presenter, passing to it the view and any model objects. The ASPX page is not responsible for attaching the presenter to a view, nor calling "InitView" on the presenter. Its only job is to wire up the presenter with the view instance and model objects, and to respond to events that the presenter might raise, such as a page redirect or some type of status event.

This example is implemented as the "Customer" module in the sample application.

Collapse

Note: The code below is used to highlight the main points of this design. Please see the sample application for a working model.
The Presenter
public class Presenter
{
public Presenter(IView view, IModel model)
{
this.view = view;
this.model = model;
this.view.OnViewLoad += new EventHandler<SingleValueEventArgs<bool>>(OnViewLoadListener);
this.view.SaveProducts += new EventHandler<SingleValueEventArgs<IList<IProduct>>>(SaveProductListener);
}
private void OnViewLoadListener(object sender, SingleValueEventArgs<bool> isPostBack)
{
if (!isPostBack.Value)
{
// Set the view for the first time
view.SetProducts(model.GetProducts());
}
}
private void SaveProductListener(object sender, SingleValueEventArgs<IList<IProduct>> products)
{
model.SaveProducts(products.Value);
}
}
The ASPX Page: The Starting Point
The ASPX HTML references the ASCX user control, and in code behind we have this.
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
presenter = new Presenter(this,model);
}
The ASCX User Control
protected override void OnLoad(EventArgs e)
{
EventHandler eventHandler = OnViewLoad;
if (eventHandler != null)
{
// Invoke our delegate
eventHandler(this, new SingleValueEventArgs<bool>(Page.IsPostBack));
}
base.OnLoad(e);
}
public void SetProducts(IList<IProduct> products)
{
// bind products to view
}
protected void btnSave_Click(object sender, EventArgs e)
{
// Raise our event
OnSaveProducts(GetProducts());
}
public event EventHandler<SingleValueEventArgs<string>> SaveProducts;
public virtual void OnSaveProducts(IList<IProduct>> products)
{
EventHandler<SingleValueEventArgs<IList<IProduct>>> eventHandler = SaveProducts;
if (eventHandler != null)
{
eventHandler(this, new SingleValueEventArgs<IList<IProduct>>(products));
}
}
The View Interface
public interface IView
{
event EventHandler OnViewLoad;
event EventHandler<SingleValueEventArgs<IList<IProduct>>>SaveProducts;
void SetProducts(IList<IProduct> products);
}

The Third Implemenation

The third implementation delegates the responsibility of creating the presenter, passing in the view and model, and calling "InitView" on the presenter to the ASCX user control (view). The view has a reference to its presenter. The presenter only knows about an interface to the view. The ASPX page is used to add the user control to the page, nothing further. Since the ASPX's responsibilities from the first and second implementations now fall firmly within the responsibility of the ASCX user control, my views are easily reusable throughout my application. I can drag a user control onto a new page and with it comes its presenter, all ready to go out of the box.

This example is implemented as the "Employee" module in the sample application.

Collapse

Note: The code below is used to highlight the main points of this design. Please see the sample application for a working model.
The Presenter
public class Presenter
{
public Presenter(IView view, IModel model)
{
this.view = view;
this.model = model;
}
public void InitView(bool isPostBack)
{
if(!isPostBack)
{
view.SetProducts(model.GetProducts());
}
}
public void SaveProducts(IList<IProduct> products)
{
model.SaveProducts(products);
}
}
The ASPX Page
The ASPX HTML references the ASCX user control, nothing futher in code behind.
The ASCX User Control: The Starting Point
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
presenter = new Presenter(this,model);
presenter.InitView(Page.IsPostBack);
}
public void SetProducts(IList<IProduct> products)
{
// bind products to view
}
The View Interface
public interface IView
{
void SetProducts(IList<IProduct> products);
}

Reflecting on the Implementations

With each of the implementations, there are characteristics I favor and those I have difficulty accepting. Again, since there is no true MVP framework for ASP.NET as this time, there are no constraints forcing me to adhere to one implementation. Determining your flavor of MVP really depends on the level of separation of concerns with which you are most comfortable, and to what degree you feel your classes should be testable.

I like the use of the ASPX page as the "view initializer and page redirector" with the first two implementations. I feel that this is a well suited responsibility for the ASPX page that should not reside with the view. The view, in my opinion, should only be concerned with view-specific responsibilities. Determining what defines a view-specific responsibility is debatable and something I feel like I have wrestled with too often.

In the second implementation, I prefer how the view is ignorant of the presenter. The view is decoupled from the presenter. It only raises events, and the first event it raises, "OnViewLoad," signifies the control's loading state and passes the Page's IsPostBack value. The presenter listens for events on the view interface and commands the view to do some action when responding. The ASPX page instantiates the presenter, passing in the view instance and the model. It can register for events on the presenter as it needs.

What I do not like about the first two implementations is that since the ASPX page is involved, reusing the ASCX user control requires more work. If I want to add a user control to a different ASPX page, I now need to instantiate my model-view-presenter relationship in the new ASPX page. This becomes cumbersome when I have nested MVP relationships, where one user control may contain another user control. This dependency can be removed if I assign the responsibility of instantiating the presenter with the view and model from the ASPX page to the ASCX user control (view). As a result, the view now has more responsibility, but it is now more reusable. This added responsibility is something I may not agree with philosophically, but it helps improve usability, and my classes are still testable.

While I like the idea that my view is decoupled from the presenter in the event-driven approach, there really is no need for this separation. Using events is not always intuitive and reliable, and writing unit tests for events requires a little extra effort. There is no guarantee that the presenter subscribes to all the appropriate events on the view.

After settling my philosophical debates and finally feeling comfortable with certain responsibilities of the ASPX page, ASCX user control, and presenter in ASP.NET, I have created this third implementation. This third implementation is similar to the first implementation but it omits the role of the ASPX "view initializer and page redirector." On the positive side, my view is more reusable across my application since it is more self reliant. On the negative side, my view now has the added responsibility of creating the presenter and responding to events the presenter may raise. Even though I may feel that certain responsibilities are crossing boundaries, I keep reminding myself that this is MVP in ASP.NET - this is not a true MVC framework that enforces that good separation of concerns like Monorail.

Conclusion

MVP provides a number of advantages, but to me, the two most important are separation of concerns and testability. There is a fair amount of overhead involved in using MVP, so if you are not planning on writing unit tests, I would definitely reconsider using the pattern.

As we see with the three different implementations, there are numerous ways to implement the pattern in ASP.NET. There are even more ways than what I have chosen to display. Choose an implementation that best suits your needs. I have to work hard at implementing MVP in ASP.NET, and there are certain tradeoffs I need to be willing to accept. As long as my code is testable, reusable, maintainable, and there exists a good degree of separation of concerns, I am happy.

With Microsoft's news of releasing an MVC framework for ASP.NET, there is hope on the horizon for a framework that enforces good separation of concerns and testability. The Castle Project's Monorail is another MVC framework that I highly recommend. If you cannot wait for Microsoft's MVC framework, or do not wish to port your application to Monorail at this time, then implementing MVP could be your answer.

About the Sample Project

The sample project is written in ASP.NET 2.0 using C#. I am using the Northwind database. I am using SubSonic as my data access layer. Since SubSonic is built using the active record pattern, I do have to use interfaces in order to make my DAO classes testable. For my unit testing, I am using RhinoMocks as my mocking framework.

The sample application is comprised of five projects. The WebApp, Model, Presentation layer, Presentation.Tests, and SubSonic data access layer. This sample is simplistic and should be used as a demo. I may be doing some things in code for the sake of brevity and to simplify the concepts. This is my disclaimer for not providing "production" code with all the frameworks, tools, and layers I typically create.

History

Initial Upload: November 6, 2007.

注意：
1、xmlns = "urn:nhibernate-configuration-2.2"必须加上。值urn:nhibernate-configuration-2.2和urn:hibernate-configuration-2.2效果一样。

2、use-proxy-validtor设置为false的话，POJO类的属性就不需要标记为virtual。

[Class(Table = "Users")]
    public class UserPojo
    {
        private int userID;
        private string name;
        private int age;
        private DateTime birthDate;
        private string description;

        public UserPojo()
        {
            userID = default(int);
            name = default(string);
            age = default(int);
            birthDate = default(DateTime);
            description = default(string);
        }

        [Id(0, Column = "UserID", TypeType = typeof(int))]
        [Generator(1, Class = "identity")]
        public  int UserID
        {
            get { return userID; }
            set { userID = value; }
        }

        [Property(Column = "Age", Type = "Int32")]
        public  int Age
        {
            get { return age; }
            set { age = value; }
        }

        [Property(Column = "Name", Type = "string")]
        public  string Name
        {
            get { return name; }
            set { name = value; }
        }

        [Property(Column = "BirthDate", Type = "DateTime")]
        public  DateTime BirthDate
        {
            get { return birthDate; }
            set { birthDate = value; }
        }

        [Property(Column = "Description", Type = "string")]
        public  string Description
        {
            get { return description; }
            set { description = value; }
        }
    }

在大型RIA中，动态加载技术十分重要，毕竟几百K甚至M级别的脚本让用户等待加载完了再浏览是不可能。大多数成熟的framework都有动态加载技术的实现，就是说先加载一个最基础功能，然后利用动态加载技术慢慢把所有的脚本加进来，或者说需要某个功能的时候再加载某个模块所  需要的javascript的文件。

好了不说那么多P话了，尽快进入正题来看看GI是怎么实现的动态加载技术。其实GI的load做的很复杂，因为他涉及到了进度条阿等等很多乱七八糟的东西，我们就不分析那么多东西了，来看看他最基础的东西是如何实现的吧。GI中的动态加载有两种，一种是用的是XMLHttpRequest来请求脚本内容，另一种则是加入一个 <script>标签的方式来动态加入脚本以达到动态加载的功能。网上也许还有其它得方法，但其它得方法也都是根据这两种演变来的，还是以这两种为基础得。我们来看看它是如何实现的。

首先是第一种

呵呵，XMLHttpRequest的GET请求就可以吧js文件拿下来，然后用eval执行所有的脚本，这样就达到了加载脚本的功能了。方法也很简单，也就不用多介绍什么了吧。不过我记着有人说过js必须要UTG-8格式存的，但测试了一下，不用好像也可以。

我们看在package。Js文件里面有个有意思的方法

  /**
   * Ensures that one or more classes is available before this method returns. Any class that fails to load will
   * throw an error. Only classes that can be found by the system class loader may be loaded in this manner.
   *
   * @param strClass {String} the fully-qualified names of the classes to load.
   * @since 3.2
   */
  jsx3.require = function(strClass) {
    for (var i = 0; i < arguments.length; i++) {
      var className = arguments[i];
      className = jsx3._REQUIRE_MAP[className] || className;
      if (jsx3.Class.forName(className) == null)
        jsx3.CLASS_LOADER.loadClass(className);
    }
  };

需要说明的是jsx3.ClASS_LOADER.loadClass()方法中其实就是调用了loadJSFileSync()方法，这个方法就是在调用类之前如果该类没有被加载将会在被load一次做到需要什么才用什么，不会把所有Javascipt都加载进来。

然后我们再来看第二种方法，添加标签的方式来load脚本

呵呵，相信大家都能看懂吧，就是在head标签中加入了script标签，src当然就是重点了，而如何判断脚本加载结束，也明确的告诉我们，在IE下用onreadystatechange，在Firefox下用onload。呵呵，好像很简单吧。

到这里，我突然想到一个问题，script标签好像功能很强大啊，竟然可以用来读服务器上的Javascript文件，跟XMLHttpRequest有同样的功能啊，看来这个东西可以被我们来利用一下了，做点手脚也许会有不同的效果哦，来看。

首先我们写一个Handlers用来模拟一个Javascript文件，然后用这个handler来生成返回的内容，

这个Handler中我只是返回了一段alert，呵呵，下面用script来加载他吧，刚才看到的一样，只是script中src我们做了点手脚，嘿嘿指向的是demo2.js?action=city22，哈哈看到了吧，就是个GET访问方式啊！

测试成功，哈，看来还真是能模拟一个XMLHttpRequest了。

Windows95/98对Dos/Win3.x作了许多重大改进，在文件系统方面，它除了采用长文件名替代Dos中的8.3文件名以外，引入外壳名字空间（Shell Name Space）来代Dos文件系统是其又一大突破．本文将简要地介绍如何在Windows 95/98或Windows NT4.0以上版本。

1. 简介

   　　在Dos/Win3.x中，每个逻辑分区构成一棵目录树，文件系统由这一统一的根，而且每个目录或文件必须一一对应于文件系统中客观存在的项。但Windows引入了“外壳名字空间”（ Shell Name Space）的概念之后，这一切就都变了。

   　外壳名字空间是Windows下的标准文件系统，它大大扩展了Dos文件系统，形成了以“桌面”（Desktop）为根的单一的文件系统树，原有的Ｃ盘、Ｄ盘等目录树变成了“我的电脑”这一外壳名字空间子树的下一级子树，而像“控制面板”、“回收站”、“网上邻居”等应用程序及“打印机”等设备也被虚拟成了外壳名字空间中的节点。另外，与ＤＯＳ中物理存储只能和文件系统项一一对应这一点不同的是，一个实际目录在外壳名字空间中可以表现为不同的项。例如“我的文档”与“C;\My Documents”其实都指向“C;\My Documents”目录，但它们在外壳名字空间中是不同的项。如果我们运行Windows 自带的“Windows资源管理器”看一下的话，那么在它的左部树型视图中我们就可以清楚的看到整个外壳名字空间替代ＤＯＳ文件系统，Windows在文件系统的组织与管理上终于有了质的飞跃。

   　　为了区别于ＤＯＳ中“目录”的概念，Windows引入了“文件夹”（Folder）的概念。“文件夹”一般是指外壳名字空间树中的非叶节点，既可以是ＤＯＳ下的目录，也可是“控制面板”、“回收站”这类虚拟的目录。但外壳名字空间中有些项本身并不是文件夹（即不具有文件夹属性），但却含有子文件夹，比如“网上邻居”等。以下为讲座方便，我们也认为它们是文件夹。

   　　在下面的讲座过程中我们将用“文件系统”一词来指代ＤＯＳ文件系统，而用“外壳名字空间”一词来指代Windows中的外壳名字空间：另外用“文件”一词来指代外壳名字空间这棵树中的叶节点（虽然它们不都是物理存储上的文件）。

   　　在Windows中，Win3.x的文件操作函数，如FindFirstFile、FindNextFile、SetCurrentDirectory等，虽然仍可使用，但用它们只能浏览文件系统，却无法浏览与操纵整个外壳名字空间。要浏览Windows中的外壳名字空间，就必须使用一套全新的、基于ＣＯＭ（组件对象模型）基础上的方法。

2. 新的“路径”PIDL

   　在讨论基于　COM的方法之前，我们先来介绍一下外壳名字空间中“路径”的表示问题。DOS的字符串路径只能表示文件系统，而无法表示整个外壳名字空间，所以外壳名字空间提供了一种“路径”的替代物椩乇晔斗斜恚虺莆?/FONT>PIDL）。

   　　PIDL是一个元素类型为ITEMIDLIST结构的数组，数组中元素的个数是未知的，但紧接着数组末尾的必是一个双字节的零。每个数组元素代表了外壳名字空间树中的一层（即一个文件夹或文件），数组中的前一元素代表的是后一元素的父文件夹。由此可见，PIDL实际上就是指向一块由若干个顺序排列的ITEMIDLIST结构组成、并在最后有一个双字节零的空间的指针。所以PIDL的类型就被Windows定义为ITEMIDLIST结构的指针。

   　　PIDL亦有“绝对路径”与“相对路径”的概念。表示“相对路径”的PIDL（本文简称为“相对PIDL”）只有一个ITEMIDLIST结构的元素，用于标识相对于父文件夹的“路径”；表示“绝对路径”的PIDL（简称为“绝对PIDL”）有若干个ITEMIDLIST结构的元素，第一个元素表示外壳名字空间根文件夹（“桌面”）下的某一子文件夹A，第二个元素则表示文件夹A下的某一子文件夹B，其余依此类推。这样绝对PIDL就通过保存一条从“桌面”下的直接子文件夹或文件的绝对PIDL与相对PIDL是相同的，而其他的文件夹或文件的相对PIDL就只是其绝对PIDL的最后一部分了。

   　　但现在就出现了一个问题：即“桌面”的表示问题。外壳名字空间中其他各项都可以用从“桌面”开始的绝对PIDL加以表示，但“桌面”的PIDL数组显然一个元素都没有。这样就只剩下PIDL数组最后的那个双字节的零了。所以，“桌面”的PIDL就是一个16位的零。注意：“桌面”内容是一个双字节的零。另外，虽然“桌面”表示的是“C:\ Windows \Desktop”文件夹（这里假定Windows的系统目录为“C:\ Windows”）的内容，但“桌面”与“C:\ Windows \Desktop”文件夹的PIDL是完全不同的。这一点同样适用于“我的文档”与“C:\ My Documents”等文件夹。

   　　DOS中的路径是一个字符串，但PIDL是一种二进制结构，所以我们不能直接从PIDL中获知它所代表的到底是哪个文件夹或文件，而必须调用相应的函数把它转换成代表路径的字符串。如果某绝对PIDL是文件系统的一部分，则调用SHGetPathFromIDList函数即可；但如不是，就无法获得路径字符串了，因为DOS中根本就不存在这种路径。但很可惜的是，Windows并没有提供一个函数来让我们方便地把文件系统的路径字符串转换成PIDL。不过我们可用一个我们自己实现的函数ParsePidlFromPath（）来达目的（具体函数的实现见下文）。

   　　PIDL的创建与释放一般并不使用C++的new和delete操作或C语言的malloc和free函数,而必须使用专门的方法进行.首先调用SHGEetMallocI函数得到Malloc接口(COM接口的一种,关于COM接口下面将详述)的指针,再调用该接口的Alloc方法为PIDL分配空间,或调用该接口的Free方法释放某个PIDL占用的空间。最后调用该接口的Release方法释放该接口。

   　除了下面将要介绍的IShellFolder、IEnumIDList等COM接口可以操作PIDL外，还有很多以SH开头的Windows API函数也可操作PIDL，不过一般这些函数都要求使用绝对PIDL作参数。例如SHGetFileInfo函数可得到某一PIDL所指对象的各种信息，包括名字、图标、属性等；SHFileOperation函数可对外壳名字空间中的项进行拷贝、移动、改名、删除等操作；SHBrowseForFolder可以显示一个让用户选择外壳名字空间中某一文件夹的浏览对话框.

3. 基于COM的方法

• Download PagingTest Solution (C#) - 55.8 Kb
• Download Paging_Procedures SQL script - 2.48 Kb
• Download Paging_LargeTable SQL script - 0.6 Kb

Introduction

The paging of a large database resultset in Web applications is a well known problem. In short, you don't want all the results from your query to be displayed on a single Web page, so some sort of paged display is more appropriate. While it was not an easy task in the old ASP, the DataGrid control in the ASP.NET simplifies this to a few lines of code. So, the paging is easy in ASP.NET, but the default behavior of the DataGrid is that all resulting records from your query will be fetched from SQL server to the ASP.NET application. If your query returns a million records this will cause some serious performance issues (if you need convincing, try executing such a query in your web application and see the memory consumption of the aspnet_wp.exe in the task manager). That's why a custom paging solution is required where desired behavior is to fetch only the rows from the current page.

There are numerous articles and posts concerning this problem and several proposed solutions. My goal here is not to present you with an amazing solves-it-all procedure, but to optimize all the existing methods and provide you with a testing application so you can do evaluation on your own. Here is a good starting point article which describes many different approaches and provides some performance test results:

How do I page through a recordset?

I was not satisfied with the most of them. First, half of the methods use old ADO and are clearly written for the "old" ASP. The rest of the methods are SQL server stored procedures. Some of them yield poor response times as you can see from the author’s performance results at the bottom of the page, but several have caught my attention.

Generalization

The three methods I decided to closely look into are the ones the author calls TempTable, DynamicSQL and Rowcount. I'll refer to the second method as the Asc-Desc method in the rest of this text. I don't think DynamicSQL was a good name, because you can apply dynamic SQL logic to the other methods too. The general problem with all these stored procedures is that you have to assess which columns you'll allow sorting for and that won't probably be just the PK column(s). This leads to a new set of problems – for each query you want to display via paging you must have as many different paging queries as you have different sorting columns. This means that you will either have a different stored procedure (regardless of the paging method applied) for each sorting column or you'll try to generalize this to only one stored procedure with the help of dynamic SQL. This has a slight performance impact, but increases maintainability if you need to display many different queries using this approach. Thus, I’ll try to generalize all of the stored procedures in this text with dynamic SQL, but in some cases it will be possible to achieve only a certain level of generalization, so you’ll still have to write separate stored procedures for some complex queries.

The second problem with allowing other sorting columns beside the PK column(s) is that if those columns are not indexed in some way, none of these methods will help. In all of them a paged source must be sorted first and the cost of using ordering by non-indexed column is immense for large tables. The response times are so high that all the procedures are practically unusable in this case (the response varies from couple of seconds to couple of minutes depending on the size of the tables and the starting record being fetched). The indexing of other columns brings more performance issues and may be undesirable, for example it might significantly slow you down in a situation where you have a lot of daily imports.

TempTable

The first one I would comment on is the TempTable method. This is actually a widely proposed solution and I encountered it several times. Here is another article that describes it along with the explanation and a sample how to use custom paging with the DataGrid:

ASP.NET DataGrid Paging Part 2 - Custom Paging

The methods in both articles could be optimized with just the Primary Key data copied to the temp table and then doing the join with the main query. Therefore, the essence of this method would be the following

CREATETABLE #Temp (
    ID intIDENTITYPRIMARYKEY,
    PK  /* here goes PK type */
)

INSERTINTO #Temp SELECT PK FROM Table ORDERBY SortColumn

SELECT ... FROM Table JOIN #Temp temp ON Table.PK = temp.PK ORDERBY temp.ID 
WHERE ID > @StartRow AND ID < @EndRow

Asc-Desc

This method uses default ordering in a subquery and then applies the reverse ordering. The principle goes like this

DECLARE @temp TABLE (
    PK  /* PK Type */ NOTNULLPRIMARY 
)

INSERTINTO @temp 
SELECT TOP @PageSize PK FROM (
    SELECT TOP (@StartRow + @PageSize) 
    PK, 
    SortColumn /*If sorting column is defferent from the PK, SortColumn must 
                 be fetched as well, otherwise just the PK is necessary */ 
    ORDERBY SortColumn /* default order – typically ASC */) 
ORDERBY SortColumn /* reversed default order – typically DESC */

SELECT ... FROM Table JOIN @Temp temp ON Table.PK = temp.PK 
ORDERBY SortColumn /* default order */

RowCount

The base logic of this method relies on the SQL SET ROWCOUNT expression to both skip the unwanted rows and fetch the desired ones:

DECLARE @Sort /* the type of the sorting column */
SET ROWCOUNT @StartRow
SELECT @Sort = SortColumn FROM Table ORDERBY SortColumn
SET ROWCOUNT @PageSize
SELECT ... FROM Table WHERE SortColumn >= @Sort ORDERBY SortColumn

SubQuery

There are 2 more methods I’ve taken into consideration, and they come from different resources. The first one is well known triple query or the SubQuery method. The most thorough approach is the one I’ve found in the following article

Server-Side Paging with SQL Server

Although you'll need to be subscribed, a .zip file with the SubQuery stored procedure variations is available. The Listing_04.SELECT_WITH_PAGINGStoredProcedure.txt file contains the complete generalized dynamic SQL. I used a similar generalization logic with all other stored procedures in this text. Here is the principle followed by the link to the whole procedure (I shortened the original code a bit, because a recordcount portion was unnecessary for my testing purposes).

SELECT ... FROM Table WHERE PK IN 
    (SELECT TOP @PageSize PK FROM Table WHERE PK NOT IN
        (SELECT TOP @StartRow PK FROM Table ORDERBY SortColumn)
    ORDERBY SortColumn)
ORDERBY SortColumn

Cursor

I’ve found the last method while browsing through the Google groups, you can find the original thread here. This method uses a server-side dynamic cursor. A lot of people tend to avoid cursors, they usually have poor performance because of their non-relational, sequential nature. The thing is that paging IS a sequential task and whatever method you use you have to somehow reach the starting row. In all the previous methods this is done by selecting all rows preceding the starting row plus the desired rows and then discarding all the preceding rows. Dynamic cursor has the FETCH RELATIVE option which does the “magic” jump. The base logic goes like this

DECLARE @PK /* PK Type */
DECLARE @tblPK TABLE (
    PK /* PK Type */ NOTNULLPRIMARYKEY
)

DECLARE PagingCursor CURSOR DYNAMIC READ_ONLY FOR
SELECT @PK FROM Table ORDERBY SortColumn

OPEN PagingCursor
FETCH RELATIVE @StartRow FROM PagingCursor INTO @PK

WHILE @PageSize > 0AND @@FETCH_STATUS = 0BEGININSERT @tblPK(PK) VALUES(@PK)
    FETCH NEXT FROM PagingCursor INTO @PK
    SET @PageSize = @PageSize - 1END

CLOSE PagingCursor
DEALLOCATE PagingCursor

SELECT ... FROM Table JOIN @tblPK temp ON Table.PK = temp.PK 
ORDERBY SortColumn

Generalization of Complex Queries

As pointed out before, all the procedures are generalized with dynamic SQL, thus, in theory, they can work with any kind of complex query. Here is a complex query sample that works with Northwind database.

Collapse

SELECT Customers.ContactName AS Customer, 
       Customers.Address + ', ' + Customers.City + ', ' + 
                                                Customers.Country AS Address, 
       SUM([Order Details].UnitPrice*[Order Details].Quantity) AS
                                                          [Total money spent] 
FROM Customers
INNERJOIN Orders ON Customers.CustomerID = Orders.CustomerID
INNERJOIN [Order Details] ON Orders.OrderID = [Order Details].OrderID
WHERE Customers.Country <> 'USA' AND Customers.Country <> 'Mexico'
GROUPBY Customers.ContactName, Customers.Address, Customers.City, 
         Customers.Country 
HAVING (SUM([Order Details].UnitPrice*[Order Details].Quantity))>1000ORDERBY Customer DESC, Address DESC

Collapse

EXEC ProcedureName
/* Tables */
'Customers
INNERJOIN Orders ON Customers.CustomerID = Orders.CustomerID
INNERJOIN [Order Details] ON Orders.OrderID = [Order Details].OrderID',
/* PK */
'Customers.CustomerID',
/* ORDERBY */
'Customers.ContactName DESC, Customers.Address DESC',
/* PageNumber */
2,
/* Page Size */
10,
/* Fields */
'Customers.ContactName AS Customer,
Customers.Address + '', '' + Customers.City + '', '' + Customers.Country 
AS Address, 
SUM([Order Details].UnitPrice*[Order Details].Quantity) AS [Total money spent]',
/* Filter */
'Customers.Country <> ''USA'' AND Customers.Country <> ''Mexico''',
/*Group By*/
'Customers.CustomerID, Customers.ContactName, Customers.Address, 
 Customers.City, Customers.Country 
HAVING (SUM([Order Details].UnitPrice*[Order Details].Quantity))>1000'

Note that in the original query, aliases are used in the ORDER BY clause. You can't do that in paging procedures, because the most time-consuming task in all of them is skipping rows preceding the starting row. This is done in various ways, but the principle is not to fetch all the required fields at first, but only the PK column(s) (in case of RowCount method the sorting column), which speeds up this task. All required fields are fetched only for the rows that belong to the requested page. Therefore, field aliases don't exist until the final query, and sorting columns have to be used earlier (in row skipping queries).

The RowCount procedure has another problem, it is generalized to work with only one column in the ORDER BY clause. The same goes for Asc-Desc and Cursor methods, though they can work with several ordering columns, but require that only one column is included in the PK. I guess this could be solved with more dynamic SQL, but in my opinion it is not worth the fuss. Although these situations are highly possible, they are not that frequent. Even if they are, you can always write a separate paging procedure following the principles above.

Performance Testing

I used these 4 methods in my tests, if you have a better one, I’d be glad to know about it. Nevertheless, I wanted to compare these methods and measure their performance. The first thought was to write an ASP.NET test application with paged DataGrid and then measure page response. Still, this wouldn’t reflect the true response time of the stored procedures, so the console application seemed more appropriate. I also included a web application, not for performance testing, but rather as an example of how DataGrid custom paging works with these stored procedures. They are both incorporated in the PagingTest Solution.

I used the auto generated large table for my tests and inserted around 500 000 records in it. If you don’t have a large table to experiment on, you can download the script for a table design and stored procedure for data generation here. I didn't want an identity column for my PK, I used the uniqueidentifier instead. If you'll use this script, you may consider to add an identity after you generate the table. It will add numbers sorted by PK and you'll have an indication that correct page is fetched when you call a paging procedure with PK sorting.

The idea behind performance testing was to call a specific stored procedure many times through a loop and then measure the average response time. Also, in order to remove caching deviations and to model the real situation more accurately – multiple calls to a stored proc with the same page fetched each time seemed inappropriate. Thus, a random sequence of the same stored procedure with a set of different page numbers was required. Of course, a set of different page numbers assumes fixed number of pages (10 – 20) where each page would be fetched many times, but in a random sequence.

It’s not hard to notice that response times depend on the distance of the fetched page from the beginning of the resultset. The further the starting record is, more records need to be skipped. This is the reason I didn’t include first 20 pages in my random sequence. Instead I used the set of 2^N pages. A loop was set to a (number of different pages)*1000. So, every page was fetched around 1000 times (more or less because of a random distribution).

Results

Conclusion

The methods performed in the following order, starting from the best one - RowCount, Cursor, Asc-Desc and Subquery. The behavior in the lower portion was especially interesting, because in many real situations you'll browse beyond the first five pages rarely, so the Subquery method might satisfy your needs in those cases. It all depends on the size of your resultset and the prediction how frequently will the distant pages be fetched. You might use the combination of methods as well. As for myself, I decided to use the RowCount method wherever possible. It beaves quite nice, even for the first page. The "wherever possible" part stands for some cases where it's hard to generalize this method, then I would use the Cursor (possibly combined with the SubQuery for the first couple of pages).

Update 2004-05-05

The main reason I wrote this article was the feedback from the vast programming community. In a couple of weeks I'll be starting work on a new project. The preliminary analysis showed that there's going to be a couple of very large tables involved. These tables will be used in many complex joined queries and their results will be displayed in the ASP.NET application (with sorting and paging enabled). That's why I invested some time in research and pursue for the best paging method. It wasn't just the performance that interested me, but also the usability and maintainability.

Now the invested time has started to pay off already. You can find a post by C. v. Berkel below (many thanks) in which he found a flaw in the RowCount method. It won't work correctly if the sorting column is not unique. The RowCount method performed the best in my tests, but now I am seriously considering not using it at all. In most cases sorting columns (besides the PK) won't be unique. This leaves me with the Cursor method as the fastest and applicable to most situations. It can be combined with the SubQuery method for the first couple of pages and possibly with the RowCount method for unique sorting columns.

Another thing which may be worth mentioning is that there's a tiny flaw in the Asc-Desc method as well. It always returns the PageSize number of records for the last page and not the actual number (which may be lower than the PageSize). The correct number can be calculated but since I don't intend to use this procedure (because of how it performed), I didn't want to improve it any further.

本文将通过以下四个案例来分析C#中的接口究竟是如何工作的。

1、公有方法实现接口方法

尽管C#在定义接口时不用指明接口方法的访问控制方式，但默认接口方法均为public型（这可以从反编译的IL代码中看到）。下面是使用Reflector查看的接口IL代码

.class private interface abstract auto ansi IControl
{
   .method public hidebysig newslot abstract virtual instance void Paint() cil managed
   {
   }
}

实现接口的类需要实现所有接口方法。通常情况下，接口的实现方法也为public型。如下案例：

using System ;
interface IControl 
{
   void Paint();
}
public class EditBox: IControl 
{
   public void Paint() 
   {
      Console.WriteLine("Pain method is called!");
   }
}
class Test 
{
   static void Main() 
   {
      EditBox editbox = new EditBox(); 
      editbox.Paint();
      ((IControl)editbox).Paint();
   }
}

程序的执行结果为：

Pain method is called!
Pain method is called!

接口就好像是关系型数据库中的一对多表，一个接口对应多个接口方法，每个接口方法又对应虚拟方法表（VMT）中的某个公有或私有方法。上面代码在内存中的镜像可由下图描述：

从图中我们可以看到直接对Paint方法的调用以及通过接口对Paint方法的调用。可见通过接口对方法进行调用需要多出一道转换工作，因此执行效率不如直接调用。

2、私有方法不能实现接口方法

如果想将接口方法直接实现为私有方法是办不到的。下面的EditBox的代码中Paint方法没有特殊说明，默认为private，导致代码无法执行：

using System ;
interface IControl 
{
   void Paint();
}
public class EditBox: IControl 
{
   void Paint() 
   {
      Console.WriteLine("Pain method is called!");
   }
   public void ShowPaint()
   {
      this.Paint();
      ((IControl)this).Paint();
   }
}
class Test 
{
   static void Main() 
   {
      EditBox editbox = new EditBox(); 
      editbox.ShowPaint();
   }
}

程序在编译时将显示如下编译错误：““EditBox”不会实现接口成员“IControl.Paint()”。“EditBox.Paint()”或者是静态、非公共的，或者有错误的返回类型。”

为什么会这样呢？如图：

这是由于接口规范中的方法默认的访问权限是public，而类中的默认访问权限是default，也就是说private，因此导致权限范围收缩，两者权限并不相同，所以必须将类的权限调整为public才可以使上面的代码得以执行。

3、实现专门的接口方法（1）

代码如下：

using System ;
interface IControl 
{
   void Paint();
}
public class EditBox: IControl 
{
   void Paint() 
   {
      Console.WriteLine("Pain method is called!");
   }
   void IControl.Paint() 
   {
      Console.WriteLine("IControl.Pain method is called!");
   }
   public void ShowPaint()
   {
      this.Paint();
      ((IControl)this).Paint();
   }
}
class Test 
{
   static void Main() 
   {
      EditBox editbox = new EditBox(); 
      editbox.ShowPaint();
      //editbox.Paint();
      ((IControl)editbox).Paint();
   }
}

EditBox类拥有一私有Paint方法，但这并不是接口方法的实现（上例已经分析过）。EditBox类中还包含了一“void IControl.Paint()”方法， 是该方法复写了接口的Paint方法，该方法是私有的（通过IL代码可以看出）。

注意：“void IControl.Paint()”前不能加任何的修饰限定符号，诸如public、private等，这在C#的语法中是不允许的。该方法反编译得到的IL代码如下：

.class public auto ansi beforefieldinit EditBox
      extends object
      implements IControl
{
      .......
      .method private hidebysig newslot virtual final instance void IControl.Paint() cil managed
      {
            .override IControl::Paint
      }
}

程序运行时内存中的镜像可简化表示为：

程序执行结果如下：

Pain method is called!
IControl.Pain method is called!
IControl.Pain method is called!

我们之所以可以通过((IControl)editbox).Paint()方法访问到代码是因为接口方法Paint是公有的。但是我们不能通过editbox.Paint()方法访问到代码是因为EditBox的Paint方法是私有的。 在EditBox内部，通过ShowPaint方法可以同时访问私有的Paint方法与接口IControl.Paint方法。

4、实现专门的接口方法（2）

如果EditBox中的Pait方法为公有并且同时提供了IControl.Paint方法，程序将是如何运行的呢？代码如下：

using System ;
interface IControl 
{
   void Paint();
}
public class EditBox: IControl 
{
   public void Paint() 
   {
      Console.WriteLine("Pain method is called!");
   }
   void IControl.Paint() 
   {
      Console.WriteLine("IControl.Pain method is called!");
   }
}
class Test 
{
   static void Main() 
   {
      EditBox editbox = new EditBox(); 
      editbox.Paint();
      ((IControl)editbox).Paint();
   }
}

程序执行结果如下：

Pain method is called!
IControl.Pain method is called!

程序执行时内存布局如下：

可见，EditBox中公有的Paint方法并不是接口实现方法，真正的接口实现方法是IControl.Paint，这将导致editbox.Paint()方法与((IControl)editbox).Paint()的执行结果并不一样。

5、结论

接口方法的实现通常是通过类中的公有方法实现的；

在一些特殊情况下（代码隐藏、一个类实现的两个接口具有相同的接口方法等），需要专门实现某个接口的方法。