getRealPath

用法如：

String uploadDir = getServletContext().getRealPath("/upload");

if(uploadDir == null){
out.print("无法访问该目录！");
return;
}
File fDir = new File(uploadDir);
if(!fDir.exists()){
if(!fDir.mkdirs()){
out.print("创建目录失败");
return;
}
}

 

(_)

在ASP.NET 2.0出现之前，ASP.NET源代码页面只不过是部署到服务器上的一个.aspx文件，并且位于一个特殊的文件夹中。磁盘上的.aspx资源与文件之间必须一一对应。在ASP.NET 2.0中，虚拟路径提供程序机制允许我们虚拟化处理大量文件，甚至可以处理一个目录结构。我们可以从文件系统的物理结构中抽象出Web内容。为了满足SharePoint的需要而建立的虚拟路径提供程序，被证明也适用于ASP.NET开发人员(SharePoint的下一个版本将建立在ASP.NET 2.0之上)。例如，我们可以注册一个路径提供程序，并向ASP.NET提供从一个数据库中读取的页面的源代码(听起来很熟悉，不是吗?是的，这正是SharePoint基于ASP.NET 2.0所实现的，而且将来还是这样)。

1. 虚拟路径提供程序的结构

虚拟路径提供程序(virtual path provider，简称VPP)是一个继承VirtualPathProvider类，并实现了Web应用程序的虚拟文件系统的类。在这样一个虚拟文件系统中，实际上使用自定义的数据存储(而不是文件系统)作为文件和目录。与处理一个ASP.NET请求相关的大多数文件都可以存储在一个虚拟文件系统中，这些文件包括ASP.NET页面、主题、母版页、用户控件、映射到一个build提供程序的自定义资源以及静态Web资源(诸如HTML页面和图像)。

VPP不能提供全局资源(诸如global.asax和web.config)和保留文件夹(诸如Bin、App_Code、App_Data、App_GlobalResources和任何一个App_LocalResources文件夹)的内容。表1.12详细描述了在一个VPP组件实例中要重写的成员。

表1.12 VirtualPathProvider类的成员

编写自定义的VPP时，重要的是重写GetFile和GetDirectory，并谨慎地使用Previous属性。下面给出了一个实例：

public override VirtualFile GetFile(string virtualPath)

{

if (IsPathVirtual(virtualPath))

return new YourVirtualFile(virtualPath, this);

else

return Previous.GetFile(virtualPath);

}

在上述代码中，IsPathVirtual是一个private函数，它只是确定你的VPP能否处理该虚拟路径。如果不能，则沿着ASP.NET链把请求向下传递到下一个VPP。如果忽略了对Previous的调用，则该请求不会被处理。

private bool IsPathVirtual(string virtualPath)

{

// For example

// Check the virtual path against your data store

}

有关的更多信息和范例代码，请参考MSDN联机文档。

2. 虚拟文件的结构

虚拟路径提供程序通过接受URL，并检查是否已注册了一个处理该URL的VPP来工作的。如果已经注册了，则该VPP返回那个路径的ASP.NET源代码。VPP通过一个继承自VirtualFile类的对象返回虚拟路径的源代码。

表1.13 VirtualFile类的成员

编写自定义的虚拟文件类时的关键问题是重写Open方法，并使它为虚拟资源的内容返回一个只读流。在Open方法中，使用虚拟路径作为键来访问数据存储和检索源代码。有关的更多信息和范例代码，请参考MSDN联机文档。

3. 注册一个虚拟路径提供程序

与大多数提供程序不同的是，虚拟路径提供程序不是通过web.config文件注册的。我们既可以在Application_Start全局事件中注册VPP，也可以通过把静态的AppInitialize方法添加到App_Code文件夹中部署的某个类来注册。下面给出了一个可以放入App_Code文件中用来注册一个VPP的示例类：

public static class AppStart

{

public static void AppInitialize()

{

// Add a new VPP to the chain

MyPathProvider vpp = new MyPathProvider();

HostingEnvironment.RegisterVirtualPathProvider(vpp);

}

}

环境类的名称是任意的；AppInitialize的名称和签名则不是。如果在App_Code文件夹中存储的不同类中存在多个具有此名称的静态方法，则会得到一个编译错误。

重要提示   在任何页面解析或编译之前注册虚拟路径提供程序非常重要。如果在应用程序或页面生存期的其他地方注册路径提供程序(例如，在web.config中)，则可能会出现一些意想不到的结果。例如，在Page_Load中，没有任何语法方面的要求会阻止我们注册一个VPP。但是，如果在页面程序集生成之后注册该VPP，则无法使该页面与程序集之间的联系无效。由此造成的后果是，在请求页面时将忽略VPP。在一个页面事件内注册一个VPP仍然是合理的，但只能从一个不是由VPP服务的并且在VPP服务的任何页面之前被调用的页面中注册VPP。可以看出，这种情况并不正常。

小    结

自1.0版以来，ASP.NET就一直即时动态地编译几种文件类型，特别是.aspx Web页面。页面文件在应用程序第一次需要它们时自动地按要求编译。对动态编译的文件的源代码所作的任何更改，都会自动地使对应的程序集无效，然后重新建立该程序集。这种机制大大简化了应用程序开发，因为开发人员只需保存文件并刷新页面，就可以马上把变更应用于应用程序。

在ASP.NET 2.0中，虽然高层模式保持不变，但是底层机制发生了重大变化。新的build系统自动地管理相当多的文件类型，包括ASP.NET页面、母版和主题文件、资源和XSD架构。这些文件提供了对期望结果的描述，并使用一个隐藏得组件来解析内容和生成一个可编译的类。新的ASP.NET build系统不需要在Visual Studio集成开发环境(IDE)进行显式的预编译，并提供了一个可扩展的模型，该模型允许增加新的文件类型。build提供程序是该模型的核心。通过编写自定义的build提供程序，可以让ASP.NET维护和编译我们自己的资源。build提供程序是Visual Studio 2005中一流的IntelliSense功能背后的核心，同时也是ASP.NET站点，预编译幕后的主要技术。

本章要点

þ        对.aspx资源(即，ASP.NET页面)的请求，被映射到一个实现了IHttpHandler接口的托管类。如果该类不存在，则动态地创建它。

þ        动态页面编译涉及两个步骤：解析.aspx文件的内容，然后生成一个类文件并被编译成一个程序集。在ASP.NET 1.x中，该模型仅支持几个预定义的文件类型，而现在被重构和扩展，也可以支持自定义的文件类型。

þ        build提供程序是系统组件，用于解析具有给定扩展名的文件，并返回一个要编译的类文件。build提供程序在内部通常使用CodeDOM API来生成代码树。我们可以编写自定义的build提供程序，让ASP.NET根据文本描述生成自己的类。

þ        ASP.NET 2.0定义了几个保留文件夹，只用于保存某些类型的资源，诸如类文件、页面资源和WSDL文档。

þ        在ASP.NET 2.0中，可以对一个站点进行本地预编译，以消除由于编译而造成的首次命中延迟；此外，也可以对站点进行部署预编译。在后一种情况下，我们得到网站的一个镜像，其中ASPX文件被编译成程序集，并且不部署任何源代码或标记。

()